On ven., 2012-06-22 at 11:34 +0200, Goswin von Brederlow wrote:
> #677787 gtk2-engines-xfce: Please add multiarch support

Note that this one (as investigated in the bug report by Goswin and me)
is a bit spurious. For multi-arch Gtk+ apps, a multi-arch engine
matching the theme used by the end user is needed. So, in fact *each
engine* should be multi-archified (Gtk2 and Gtk3).

But, in fact, only the most used engines might really be candidate. I
didn't really had time to check gtk2-engines-xfce (so patches are
welcome) but I think it should not be too hard (not sure if I'll have
time before the freeze though). Same goes for gtk2-engines-murrine.

Regards,
--
Yves-Alexis

"Adam D. Barratt" <adam@adam-barratt.org.uk> writes:

> On 22.06.2012 15:31, Roger Leigh wrote:
>> On Fri, Jun 22, 2012 at 09:32:15PM +0800, Thomas Goirand wrote:
>>> On 06/22/2012 05:34 PM, Goswin von Brederlow wrote:
>>> > Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
>>> > Step 2: dpkg --add-architecture i386 && apt-get update
>>> > Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)
> [...]
>>> I know we have release notes, but some don't know about them or
>>> would
>>> simply not read them. A debconf message seem really appropriate IMO.
>>
>> Could we not introduce the concept of an "upgrade script" into
>> apt-get which could be downloaded when you run "apt-get update" and
>> then run during a dist-upgrade? This could handle automation of
>> any "housekeeping" during the upgrade which would otherwise require
>> manual work detailed in the release notes.
>
> As a theoretical future enhancement, possibly. That won't help for
> squeeze to wheezy upgrades though, as squeeze's apt would need to
> include support for it.
>
> Regards,
>
> Adam

I actualy have an idea for this special case that should be quick to
implement and could help many users.

Packages with cross architecture dependencies set "X-Needs-Architecture:
<arch>[, ...]" in debian/control. Apt-get and aptitude (and maybe dpkg)
can then be patched to give a helpfull error message if the user tries
to install the package without multiarch. They can also hold back the
package until multiarch is enabled (as opposed to suggesting to remove
them as first choice) and even suggest enabling multiarch (wheezy
versions only).

The helpfull error messages and holding back packages would have to be
ported to stable apt/aptitude to be any use for upgrades. And only
people updating to the latest stable point release would benefit from
it.

In the long run though it would be helpfull for everyone. Trying to
install an armel cross compiler on amd64 could automatically detect that
this would require activating armel and suggest to do that now. And so
on. Post wheezy detecting this case could be extended to "Depends:
libfoo:arch".

MfG
Goswin



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87pq8rtc78.fsf@frosties.localnet

On Fri, 2012-06-22 at 19:37 +0200, Luk Claes wrote:
> On 06/22/2012 04:31 PM, Roger Leigh wrote:
> > On Fri, Jun 22, 2012 at 09:32:15PM +0800, Thomas Goirand wrote:
> >> On 06/22/2012 05:34 PM, Goswin von Brederlow wrote:
> >>> Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
> >>> Step 2: dpkg --add-architecture i386 && apt-get update
> >>> Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)
> >>>
> >> May I suggest that upon upgrade, we have a debconf message telling
> >> about it? We could add this in base-files or any essential package,
> >> probably one with some debconf messages already in would be a better
> >> pick. Instructions would show, IF ia32-libs old version is currently
> >> installed
> >> AND the --add-architecture i386 hasn't bee done.
> >>
> >> I know we have release notes, but some don't know about them or would
> >> simply not read them. A debconf message seem really appropriate IMO.
> >
> > Could we not introduce the concept of an "upgrade script" into
> > apt-get which could be downloaded when you run "apt-get update" and
> > then run during a dist-upgrade? This could handle automation of
> > any "housekeeping" during the upgrade which would otherwise require
> > manual work detailed in the release notes.
>
> Hmm, I'm not a fan of upgrade scripts at all. Either it's easy enough to
> automate in maintainerscripts or it should get careful review for the
> context in which it will be applied IMHO (which means the sysadmin can
> run the shipped script manually).
[...]

You can't use a maintainer script to automate, for example, installation
of another package dependent on hardware configuration. All you can do
is show a note/error prompting the user to do that. Which is rather
sad.

Ben.

--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.

On 06/23/2012 02:18 AM, Goswin von Brederlow wrote:
> Problem is that frontends will complain about ia32-libs being not
> upgradable and might suggest removing it instead of keeping it back way
> before that. At the time base-file is upgraded ia32-libs and all other
> 32bit stuff might already have been removed.

Well, you wrote it would be held back, so I reacted upon the information
you gave...

What mechanism would remove it? Is there any break / conflict somewhere
that would do that?

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FE56011.70009@debian.org">http://lists.debian.org/4FE56011.70009@debian.org

On 06/23/2012 02:48 AM, Goswin von Brederlow wrote:
> The helpfull error messages and holding back packages would have to be
> ported to stable apt/aptitude to be any use for upgrades. And only
> people updating to the latest stable point release would benefit from
> it.
>
Unfortunately, we never require that our users upgrade to the latest
point release before upgrading to stable+1. So it would be nice to
have this feature in a stable update, but this can't be a definitive
solution.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FE560CE.5070508@debian.org">http://lists.debian.org/4FE560CE.5070508@debian.org

Thomas Goirand <zigo@debian.org> writes:
> On 06/23/2012 02:48 AM, Goswin von Brederlow wrote:

>> The helpfull error messages and holding back packages would have to be
>> ported to stable apt/aptitude to be any use for upgrades. And only
>> people updating to the latest stable point release would benefit from
>> it.

> Unfortunately, we never require that our users upgrade to the latest
> point release before upgrading to stable+1. So it would be nice to have
> this feature in a stable update, but this can't be a definitive
> solution.

We've frequently required users to upgrade specific packages to newer
versions prior to the general dist-upgrade to resolve various issues, such
as for the udev transition.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87lijemtnr.fsf@windlord.stanford.edu">http://lists.debian.org/87lijemtnr.fsf@windlord.stanford.edu

On 06/23/2012 08:23 AM, Thomas Goirand wrote:
> Unfortunately, we never require that our users upgrade to the latest
> point release before upgrading to stable+1.

http://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#system-status

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FE56BCE.7010308@dogguy.org">http://lists.debian.org/4FE56BCE.7010308@dogguy.org

On Sat, June 23, 2012 08:25, Russ Allbery wrote:
> Thomas Goirand <zigo@debian.org> writes:
>> On 06/23/2012 02:48 AM, Goswin von Brederlow wrote:
>
>>> The helpfull error messages and holding back packages would have to be
>>> ported to stable apt/aptitude to be any use for upgrades. And only
>>> people updating to the latest stable point release would benefit from
>>> it.
>
>> Unfortunately, we never require that our users upgrade to the latest
>> point release before upgrading to stable+1. So it would be nice to have
>> this feature in a stable update, but this can't be a definitive
>> solution.
>
> We've frequently required users to upgrade specific packages to newer
> versions prior to the general dist-upgrade to resolve various issues, such
> as for the udev transition.

What I've seen in RHEL is that packages like up2date or yum are always
sorted to be upgraded first, and then immediately reload themselves before
they continue with the rest of the to be upgraded packages.

Perhaps this could be something for dpkg and apt - currently if you do not
take precautions you're performing big upgrades with the apt from a few
years back, while you may want to use the newest features, insights (and
bugs) straight away.

Cheers,
Thijs


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 2a7f3aeefdf4b4ba5156e0821d3e0e77.squirrel@wm.kinkh orst.nl">http://lists.debian.org/2a7f3aeefdf4b4ba5156e0821d3e0e77.squirrel@wm.kinkh orst.nl

Thomas Goirand <zigo@debian.org> writes:

> On 06/23/2012 02:18 AM, Goswin von Brederlow wrote:
>> Problem is that frontends will complain about ia32-libs being not
>> upgradable and might suggest removing it instead of keeping it back way
>> before that. At the time base-file is upgraded ia32-libs and all other
>> 32bit stuff might already have been removed.
>
> Well, you wrote it would be held back, so I reacted upon the information
> you gave...

It has to be held back. But apt-get/aptitude might select a solution
where they do get removed rather then hold back many other packages.
I'm hoping it will be held back automatically without user intervention
but that might not happen.

> What mechanism would remove it? Is there any break / conflict somewhere
> that would do that?
>
> Thomas

No relevant breaks / conflicts in ia32-libs. But there might be breaks /
conflicts in other packages or simply versioned depends that make
upgrading foo impossible as long as the squeeze ia32-libs is installed.

I'm not aware that this will happen but I also haven't tested a squeeze
-> wheezy upgrade with 32bit stuff installed. Experiece has just shown
that on large upgrades packages are easily removed instead of held back
and given the large number of updates involved users often miss a
specific one being listed.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87pq8qqoab.fsf@frosties.localnet

On Jun 23, Russ Allbery <rra@debian.org> wrote:

> We've frequently required users to upgrade specific packages to newer
> versions prior to the general dist-upgrade to resolve various issues, such
> as for the udev transition.
FWIW, what we required was to upgrade the kernel and udev at the same
time, so a normal dist-upgrade would just work.

--
ciao,
Marco