Re: The future (or non-future) of ia32-libs
Steve Langasek writes: > On Sun, Jun 24, 2012 at 03:57:29PM +0800, Thomas Goirand wrote: >> > Release notes are meant to be read once, not every time you upgrade a >> > system. Having a debconf note once might be appropriate. The second >> > time, you'll go "right, I've seen that before". The third time you go >> > "sigh, yes, I know, fuck off". The fourth time, you hit ctrl-C, and run >> > "DEBIAN_FRONTEND=noninteractive apt-get upgrade" -- and then miss >> > something that was actually important and didn't occur on previous >> > installs. > >> > Please, let's keep upgrade information in the release notes. If some >> > people don't read them, that's something we should try to fix; not by >> > trying to work around the release notes, but by making them more >> > accessible, easier to find, and more obvious instead. > >> Well, if you update apt + dpkg first, then --add-architecture i386, and >> *then only* dist-upgrade (or if we manage to update apt / dpkg in >> stable, so that it does that automatically), it wouldn't display the >> debconf. So if you were doing lots of upgrades, it would display the >> debconf screen only if you do the mistake to forget about the >> --add-architecture i386. So I don't think that my proposal is an abuse >> of debconf as you describe. > > It's an abuse of debconf because if you know the system is broken, we should > do better than just to tell the user that the system is broken. We should > either give them the option to automatically fix it on upgrade, or - better > by far - we should automatically fix it for them on upgrade. > > Why would anyone who has the ia32-libs package installed want anything *but* > to have 'dpkg --add-architecture i386' on upgrade? > > That said, I'm not sure I wouldn't also consider it an abuse of base-files > to make that package do this on upgrade. If you're going to task some > package with transitioning to multiarch, it probably makes more sense to do > it in dpkg itself. As long as we don't have a " packages for " partial architecture I don't think anything should silently add a foreign arch automatically. Also adding the architecture requires an apt-get/aptitude update and restarting the upgrade/dist-ugrade so that can't be done from maintainer scripts cleanly. I think the place where it makes sense to add a foreign architecture is in Debian-Installer. I think people who upgrade will have to read the release notes. MfG Goswin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txxz1zz0.fsf@frosties.localnet
Re: The future (or non-future) of ia32-libs
On Sun, Jun 24, 2012 at 03:57:29PM +0800, Thomas Goirand wrote: > > Release notes are meant to be read once, not every time you upgrade a > > system. Having a debconf note once might be appropriate. The second > > time, you'll go "right, I've seen that before". The third time you go > > "sigh, yes, I know, fuck off". The fourth time, you hit ctrl-C, and run > > "DEBIAN_FRONTEND=noninteractive apt-get upgrade" -- and then miss > > something that was actually important and didn't occur on previous > > installs. > > Please, let's keep upgrade information in the release notes. If some > > people don't read them, that's something we should try to fix; not by > > trying to work around the release notes, but by making them more > > accessible, easier to find, and more obvious instead. > Well, if you update apt + dpkg first, then --add-architecture i386, and > *then only* dist-upgrade (or if we manage to update apt / dpkg in > stable, so that it does that automatically), it wouldn't display the > debconf. So if you were doing lots of upgrades, it would display the > debconf screen only if you do the mistake to forget about the > --add-architecture i386. So I don't think that my proposal is an abuse > of debconf as you describe. It's an abuse of debconf because if you know the system is broken, we should do better than just to tell the user that the system is broken. We should either give them the option to automatically fix it on upgrade, or - better by far - we should automatically fix it for them on upgrade. Why would anyone who has the ia32-libs package installed want anything *but* to have 'dpkg --add-architecture i386' on upgrade? That said, I'm not sure I wouldn't also consider it an abuse of base-files to make that package do this on upgrade. If you're going to task some package with transitioning to multiarch, it probably makes more sense to do it in dpkg itself. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120624153041.gc26...@virgil.dodds.net
Re: The future (or non-future) of ia32-libs
Wouter Verhelst writes: > 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. > > No, debconf messages are the wrong tool for the job. > > Release notes are meant to be read once, not every time you upgrade a > system. Having a debconf note once might be appropriate. The second > time, you'll go "right, I've seen that before". The third time you go > "sigh, yes, I know, fuck off". The fourth time, you hit ctrl-C, and run > "DEBIAN_FRONTEND=noninteractive apt-get upgrade" -- and then miss > something that was actually important and didn't occur on previous > installs. > > Please, let's keep upgrade information in the release notes. If some > people don't read them, that's something we should try to fix; not by > trying to work around the release notes, but by making them more > accessible, easier to find, and more obvious instead. +1. MfG Goswin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq8o7wmn.fsf@frosties.localnet
Re: The future (or non-future) of ia32-libs
On 06/24/2012 06:01 AM, Wouter Verhelst 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. > > No, debconf messages are the wrong tool for the job. > > Release notes are meant to be read once, not every time you upgrade a > system. Having a debconf note once might be appropriate. The second > time, you'll go "right, I've seen that before". The third time you go > "sigh, yes, I know, fuck off". The fourth time, you hit ctrl-C, and run > "DEBIAN_FRONTEND=noninteractive apt-get upgrade" -- and then miss > something that was actually important and didn't occur on previous > installs. > > Please, let's keep upgrade information in the release notes. If some > people don't read them, that's something we should try to fix; not by > trying to work around the release notes, but by making them more > accessible, easier to find, and more obvious instead. Well, if you update apt + dpkg first, then --add-architecture i386, and *then only* dist-upgrade (or if we manage to update apt / dpkg in stable, so that it does that automatically), it wouldn't display the debconf. So if you were doing lots of upgrades, it would display the debconf screen only if you do the mistake to forget about the --add-architecture i386. So I don't think that my proposal is an abuse of debconf as you describe. Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe6c869.5080...@debian.org
Re: The future (or non-future) of ia32-libs
On Fri, Jun 22, 2012 at 08:18:03PM +0200, Goswin von Brederlow wrote: > > 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. > > Something along with: > 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. Why would they do that? Has anyone seen this happening in practice? The ia32-libs package has trivial dependencies, none of which should run into conflicts on upgrade from squeeze to wheezy. Some of the biarch library packages that ia32-libs depends on *might* go away before wheezy release, but none have yet. So there's no reason for a frontend to remove the ia32-libs package /at all/ on upgrade; it should be held back because the dependencies of the new version of the package aren't satisfiable until the package database is updated with knowledge of multiarch, but it certainly shouldn't be removed. At which point, the user just has to enable multiarch, apt-get update, and do a second apt-get dist-upgrade pass. I don't see why we would want to try any of the kludgy solutions being discussed in this thread without evidence that the above can't be made to work and kept working for release. Then we just need to document this in the release notes, which users ought to be reading anyway, and they can complete the upgrade at their leisure. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: The future (or non-future) of ia32-libs
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. No, debconf messages are the wrong tool for the job. Release notes are meant to be read once, not every time you upgrade a system. Having a debconf note once might be appropriate. The second time, you'll go "right, I've seen that before". The third time you go "sigh, yes, I know, fuck off". The fourth time, you hit ctrl-C, and run "DEBIAN_FRONTEND=noninteractive apt-get upgrade" -- and then miss something that was actually important and didn't occur on previous installs. Please, let's keep upgrade information in the release notes. If some people don't read them, that's something we should try to fix; not by trying to work around the release notes, but by making them more accessible, easier to find, and more obvious instead. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120623220134.gb7...@grep.be
Re: The future (or non-future) of ia32-libs
On 06/23/2012 03:10 PM, Mehdi Dogguy wrote: > 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 Oh, thanks for correcting me! Does this mean that modifying apt / dpkg to take care of ia32-libs is a possibility? Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe5d590.1000...@debian.org
Re: The future (or non-future) of ia32-libs
Thomas Goirand 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-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq8qqoab.fsf@frosties.localnet
Re: The future (or non-future) of ia32-libs
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-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe56bce.7010...@dogguy.org
Re: The future (or non-future) of ia32-libs
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-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe560ce.5070...@debian.org
Re: The future (or non-future) of ia32-libs
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-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe56011.70...@debian.org
Re: The future (or non-future) of ia32-libs
"Adam D. Barratt" 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: [, ...]" 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-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq8rtc78.fsf@frosties.localnet
Re: The future (or non-future) of ia32-libs
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 signature.asc Description: This is a digitally signed message part
Re: The future (or non-future) of ia32-libs
Luk Claes writes: > 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). Maybe you shouldn't think of this as a script. Rather think of it as hints for apt/aptitude to do a dist-upgrade in multiple steps. As you say the maintainer scripts should do the right thing already. So it is just a matter of splitting up the package list into smaller chunks so the upgrade process doesn't explode with a few extra actions inbetween steps. For ia32-libs the extra action would be "dpkg --add-architecture i386". For the kernel/udev the action might be "reboot". Little things like that. :))) In general the upgrade "script" could consist of lists of white/black lists of package to be processed in each step and debconf messages being displayed between steps prompting the user to do certain things before continuing. Each time dist-upgrade-by-script is run apt-get would skip all the steps that produce no change and continue from the first one that does (in case it was aborted or reboot was needed). Just an idea. Not that I think this could be done before the freeze. MfG Goswin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5nftcsr.fsf@frosties.localnet
Re: The future (or non-future) of ia32-libs
Thomas Goirand writes: > 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. > Something along with: 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. >> It appears that you have an old version of ia32-libs installed in your >> system. Debian now supports multi-arch, and the new version of >> ia32-libs (a transitional package) uses and needs this new feature. >> . >> In order to upgrade the version of ia32-libs in your system, you will >> need to do: >>dpkg --add-architecture i386 >>apt-get update >>apt-get dist-upgrade >> >> Until you do this, upgrades of ia32-libs and packages depending on >> it (wine, other examples, etc.) will not be possible. More information >> about this available at: https://wiki.debian.org/ > > I'm ok to contribute a small patch doing this. > Thoughts? Any English guy to propose a better wording? > > Cheers, > > Thomas I don't think that would be of much help but feel free to try it out with some real squeeze -> wheezy upgrades and see if you see the message before ia32-libs get removed. MfG Goswin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bokbus6c.fsf@frosties.localnet
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? Cheers Luk -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe4ad46.7000...@debian.org
Re: The future (or non-future) of ia32-libs
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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/c0411bd3da03f0beef873e944da54...@mail.adsl.funky-badger.org
Re: The future (or non-future) of ia32-libs
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. 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. Doesn't the Ubuntu updater tool do something like this already when it does a full upgrade between releases? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120622143137.gf9...@codelibre.net
Re: The future (or non-future) of ia32-libs
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. Something along with: > It appears that you have an old version of ia32-libs installed in your > system. Debian now supports multi-arch, and the new version of > ia32-libs (a transitional package) uses and needs this new feature. > . > In order to upgrade the version of ia32-libs in your system, you will > need to do: >dpkg --add-architecture i386 >apt-get update >apt-get dist-upgrade > > Until you do this, upgrades of ia32-libs and packages depending on > it (wine, other examples, etc.) will not be possible. More information > about this available at: https://wiki.debian.org/ I'm ok to contribute a small patch doing this. Thoughts? Any English guy to propose a better wording? Cheers, Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe473df.8000...@debian.org
