[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The future (or non-future) of ia32-libs

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).

> For example, if the ia32-libs package is installed, this could
> automatically update dpkg and apt-get, then automatically add the
> architecture and update prior to continuing with the upgrade.  It
> could also handle any additional work which needs doing before and
> after the upgrade of the whole distribution, or any particular
> package.  i.e. handling any work which the package maintainer
> scripts can't safely or sensibly handle.

Shipping scripts to do that would be a first step that makes much more
sense than having it automated at this stage IMHO.

> Doesn't the Ubuntu updater tool do something like this already when
> it does a full upgrade between releases?

There were quite some bugs with that tool AFAIR. Does it also cover
things that are not supported by Canonical? How does the development and
testing of the tool work?



Reply to: