Re: The future (or non-future) of ia32-libs
Steve Langasek vor...@debian.org 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 arch X packages for arch Y 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-devel-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 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-devel-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
Adam Borowski kilob...@angband.pl writes: On Sat, Jun 23, 2012 at 01:07:56PM +0200, Goswin von Brederlow wrote: 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. 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. You don't need to go between releases: every time gcc-4.7 or eglibc get updated, apt wants to remove whole architectures which didn't build these packages yet. Having it hold in such a case would be nice. That is a different situation though. There you have libfoo:amd64 and libfoo:i386 in different versions. Here you have ia32-libs depending on something that doesn't (yet) exist. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3yx80ap.fsf@frosties.localnet
Re: The future (or non-future) of ia32-libs
Wouter Verhelst wou...@debian.org 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-devel-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 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-devel-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
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-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
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-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
Thomas Goirand z...@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 (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lijemtnr@windlord.stanford.edu
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-devel-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 Sat, June 23, 2012 08:25, Russ Allbery wrote: Thomas Goirand z...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2a7f3aeefdf4b4ba5156e0821d3e0e77.squir...@wm.kinkhorst.nl
Re: The future (or non-future) of ia32-libs
Thomas Goirand z...@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-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 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-devel-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
On Jun 23, Russ Allbery r...@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 signature.asc Description: Digital signature
Re: The future (or non-future) of ia32-libs
On Sat, Jun 23, 2012 at 01:07:56PM +0200, Goswin von Brederlow wrote: 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. 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. You don't need to go between releases: every time gcc-4.7 or eglibc get updated, apt wants to remove whole architectures which didn't build these packages yet. Having it hold in such a case would be nice. -- I was born an ugly, dumb and work-loving child, then an evil midwife replaced me in the crib. 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-devel-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 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 Jun 22, Goswin von Brederlow goswin-...@web.de 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) Maybe this is easier? 1: upgrade dpkg and apt 2: dpkg --add-architecture i386 apt-get update 3: dist-upgrade as usual -- ciao, Marco signature.asc Description: Digital signature
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/please-fill 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe473df.8000...@debian.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-devel-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 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-devel-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 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-devel-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 06/22/2012 07:37 PM, 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: 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? I think we can do better than having to rely on a weird tool to fix the issues we produced by not doing a proper QA. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe4b5f6.8000...@bzed.de
Re: The future (or non-future) of ia32-libs
Thomas Goirand z...@debian.org 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/please-fill 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-devel-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
m...@linux.it (Marco d'Itri) writes: On Jun 22, Goswin von Brederlow goswin-...@web.de 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) Maybe this is easier? 1: upgrade dpkg and apt 2: dpkg --add-architecture i386 apt-get update 3: dist-upgrade as usual -- ciao, Marco Sure, that would be enough for the 1. step. There are a few more packages that need to be updated by hand for other reasons. Anything between dpkg+apt and everything but ia32-libs will be fine for me. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87395nurtn.fsf@frosties.localnet
Re: The future (or non-future) of ia32-libs
Luk Claes l...@debian.org 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-devel-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
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
Adam D. Barratt a...@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-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 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. signature.asc Description: This is a digitally signed message part
