Re: Migration path for 'Multi-Arch:allowed' packages
Ben Hutchings b...@decadent.org.uk writes: On Tue, 2012-06-12 at 17:45 +0200, David Kalnischkies wrote: On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert mgilb...@debian.org wrote: In particular, I filed a bug against dpkg requesting that it produce more informative error messages in these cases [0], but I wonder if a part of the solution shouldn't be more automated or at least presented at a higher level through apt/aptitude, etc? Chicken or the egg? You need to upgrade to support MultiArch, but you need MultiArch to upgrade⦠(beside, how would the detection for such a message look like?) [...] Maybe all maintainers who want to use Multi-Arch now in wheezy (and therefore drop amd64 packages) should get together and write a what to do after the distribution upgrade for the release notes, a (low priority) debconf message and if you want to be really fancy a transitional package which shows the same text in case the dropped binaries are executed. [...] I'd be interested in this for linux-image-amd64:i386. Currently I expect linux-image-3.2.0-n-amd64:i386 to remain in wheezy but we'll still need to advise the user to enable amd64 ready for wheezy+1. If we can document multi-arch well enough in release notes etc. then it might be possible to drop it now. Ben. Luckily you have an i386 package that will be updated to. So you can add something to the NEWS file or even pop up a debconf message telling the user about going multiarch. 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/87haua5gjg.fsf@frosties.localnet
Re: Migration path for 'Multi-Arch:allowed' packages
* Ben Hutchings b...@decadent.org.uk [120613 23:56]: On Wed, 2012-06-13 at 12:47 +0100, Wookey wrote: I added a user-oriented HOWTO to the multiarch doc-collection last month as there seemed to be a shortage of such docs to point to that weren't cryptic specifications, or talking mostly about cross-building. It may be a useful place to point people, or just lift the good bits from it: http://wiki.debian.org/Multiarch/HOWTO Very nice! Thanks. That's quite good, but for release notes I think we would need something that more tersely explains what multiarch means and that you *must* enable it if you have certain packages installed on certain architectures. Also, please be explicit about what it means to enable multiarch in this context. I presume, but am not certain, that it means to add the correct foreign architecture (i386 in the case of wine-unstable?), modify sources.list if needed, and do aptitude update (or equivalent). If this is wrong or I am missing a step, I would appreciate enlightenment! ...Marvin -- 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/20120614144809.ga13...@cleo.wdw
Re: Migration path for 'Multi-Arch:allowed' packages
Andreas Barth a...@ayous.org writes: * David Kalnischkies (kalnischk...@gmail.com) [120612 18:03]: You need to upgrade to support MultiArch, but you need MultiArch to upgrade⦠(beside, how would the detection for such a message look like?) We had discussed to export foreign-arch packages to the arches packages files at debconf. That would mean in this case that the amd64-packages file contains the i386-package wine-bin. That would allow to detect we need multi-arch packages easily (and avoid that people have to add all i386-packages to an amd64-system just to install wine-bin). Not at present. When parsing binary-amd64/Packages all Arch:i386 are filtered out and not added to the database, not as long as multiarch is not enabled. In order to get that going, we would need to document in the release notes that certain packages either need to be put on hold prior to the upgrade in case they're installed or to upgrade apt, aptitude and dpkg first. Both had been done before. The prefered default should be to keep them on hold, leave them as they are. But that probably won't work out for everyone. Documenting that they should be held back is the best that can be done there I think. But after a partial update maybe we could do better. Maybe we could add a flag X-Needs-Multiarch: arch to the few packages that need it and through that get apt-get/aptitude to generate a better error message when the required foreign architecture is not configured? 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/87aa07o8h3.fsf@frosties.localnet
Re: Migration path for 'Multi-Arch:allowed' packages
On Tue, 2012-06-12 at 17:45 +0200, David Kalnischkies wrote: On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert mgilb...@debian.org wrote: In particular, I filed a bug against dpkg requesting that it produce more informative error messages in these cases [0], but I wonder if a part of the solution shouldn't be more automated or at least presented at a higher level through apt/aptitude, etc? Chicken or the egg? You need to upgrade to support MultiArch, but you need MultiArch to upgrade… (beside, how would the detection for such a message look like?) [...] Maybe all maintainers who want to use Multi-Arch now in wheezy (and therefore drop amd64 packages) should get together and write a what to do after the distribution upgrade for the release notes, a (low priority) debconf message and if you want to be really fancy a transitional package which shows the same text in case the dropped binaries are executed. [...] I'd be interested in this for linux-image-amd64:i386. Currently I expect linux-image-3.2.0-n-amd64:i386 to remain in wheezy but we'll still need to advise the user to enable amd64 ready for wheezy+1. If we can document multi-arch well enough in release notes etc. then it might be possible to drop it now. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Re: Migration path for 'Multi-Arch:allowed' packages
+++ Ben Hutchings [2012-06-13 12:24 +0100]: On Tue, 2012-06-12 at 17:45 +0200, David Kalnischkies wrote: On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert mgilb...@debian.org wrote: In particular, I filed a bug against dpkg requesting that it produce more informative error messages in these cases [0], but I wonder if a part of the solution shouldn't be more automated or at least presented at a higher level through apt/aptitude, etc? Chicken or the egg? You need to upgrade to support MultiArch, but you need MultiArch to upgrade… (beside, how would the detection for such a message look like?) [...] Maybe all maintainers who want to use Multi-Arch now in wheezy (and therefore drop amd64 packages) should get together and write a what to do after the distribution upgrade for the release notes, a (low priority) debconf message and if you want to be really fancy a transitional package which shows the same text in case the dropped binaries are executed. [...] I'd be interested in this for linux-image-amd64:i386. Currently I expect linux-image-3.2.0-n-amd64:i386 to remain in wheezy but we'll still need to advise the user to enable amd64 ready for wheezy+1. If we can document multi-arch well enough in release notes etc. then it might be possible to drop it now. I added a user-oriented HOWTO to the multiarch doc-collection last month as there seemed to be a shortage of such docs to point to that weren't cryptic specifications, or talking mostly about cross-building. It may be a useful place to point people, or just lift the good bits from it: http://wiki.debian.org/Multiarch/HOWTO Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.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/20120613114727.gp13...@stoneboat.aleph1.co.uk
Re: Migration path for 'Multi-Arch:allowed' packages
On Wed, 2012-06-13 at 12:47 +0100, Wookey wrote: +++ Ben Hutchings [2012-06-13 12:24 +0100]: On Tue, 2012-06-12 at 17:45 +0200, David Kalnischkies wrote: On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert mgilb...@debian.org wrote: In particular, I filed a bug against dpkg requesting that it produce more informative error messages in these cases [0], but I wonder if a part of the solution shouldn't be more automated or at least presented at a higher level through apt/aptitude, etc? Chicken or the egg? You need to upgrade to support MultiArch, but you need MultiArch to upgrade… (beside, how would the detection for such a message look like?) [...] Maybe all maintainers who want to use Multi-Arch now in wheezy (and therefore drop amd64 packages) should get together and write a what to do after the distribution upgrade for the release notes, a (low priority) debconf message and if you want to be really fancy a transitional package which shows the same text in case the dropped binaries are executed. [...] I'd be interested in this for linux-image-amd64:i386. Currently I expect linux-image-3.2.0-n-amd64:i386 to remain in wheezy but we'll still need to advise the user to enable amd64 ready for wheezy+1. If we can document multi-arch well enough in release notes etc. then it might be possible to drop it now. I added a user-oriented HOWTO to the multiarch doc-collection last month as there seemed to be a shortage of such docs to point to that weren't cryptic specifications, or talking mostly about cross-building. It may be a useful place to point people, or just lift the good bits from it: http://wiki.debian.org/Multiarch/HOWTO That's quite good, but for release notes I think we would need something that more tersely explains what multiarch means and that you *must* enable it if you have certain packages installed on certain architectures. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Re: Migration path for 'Multi-Arch:allowed' packages
Hi Mike, On Mon, 11 Jun 2012 15:40:59 -0400, Michael Gilbert mgilb...@debian.org wrote: We've been getting a few bug reports from users attempting to install multiarch wine who have yet to manually enable multiarch itself. Obviously that is a failure on their part, and is easily correctable. However, I wonder if we can't make such migrations a bit more straightforward? I fail to see how it is a failure on the part of the users. How are they supposed to know that wine is now a multiarch-only package on *-amd64? One might expect unstable-tracking users to find out for themselves, but what will happen when users upgrade from Squeeze? We could ask for a specific mention in the release notes, but we'll still end up with bug reports from users who haven't read them... In particular, I filed a bug against dpkg requesting that it produce more informative error messages in these cases [0], but I wonder if a part of the solution shouldn't be more automated or at least presented at a higher level through apt/aptitude, etc? Having dpkg produce more informative error messages won't help users upgrading with apt-get or aptitude. I just rebuilt a Squeeze amd64 system to try the upgrade, and the only solutions offered are either to hold the wine package, or remove it - so dpkg never gets a chance to attempt to process the upgrade. Also, limitations in the existing testing migration tools are making wine not considered for wheezy, since those tools don't check whether dependencies for 'Multi-Arch: allowed' packages are satisfied by packages on other architectures. Short of packaging Wine64, might it be possible to have wine-bin on amd64 and kfreebsd-amd64 be a dummy package containing only a wine script which provides appropriate instructions, registered as a very-low-priority alternative using the existing infrastructure? Regards, Stephen signature.asc Description: PGP signature
Re: Migration path for 'Multi-Arch:allowed' packages
On Tue, Jun 12, 2012 at 11:45 AM, David Kalnischkies wrote: On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert wrote: In particular, I filed a bug against dpkg requesting that it produce more informative error messages in these cases [0], but I wonder if a part of the solution shouldn't be more automated or at least presented at a higher level through apt/aptitude, etc? Chicken or the egg? You need to upgrade to support MultiArch, but you need MultiArch to upgrade… (beside, how would the detection for such a message look like?) A squeeze-proposed-update could help that along, right? So, it appears that allowed is the wrong flag (although the Ubuntu wine package also uses allowed in that sense). The algorithm would look something like: if package depends on a missing native package if package is set with some new Multi-Arch: no-native flag present multiarch instructions else present missing package error Although that may not be necessary. I'm implementing a wine-bin | wine64-bin solution where the wine64-bin package simply presents multiarch instructions. It's not very elegant or ideal, but it will in fact help users along. Best wishes, Mike -- 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/CANTw=MPhLfc52RwY=6psoesqmrxtqym6mob8dgpm-ucxosu...@mail.gmail.com
Re: Migration path for 'Multi-Arch:allowed' packages
Michael, am Tue, Jun 12, 2012 at 12:57:12PM -0400 hast du folgendes geschrieben: A squeeze-proposed-update could help that along, right? no, we don't generally require people to update to the latest stable to upgrade to the next stable version. Also depending on the solution it might also not be suitable for a stable update. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Migration path for 'Multi-Arch:allowed' packages
* David Kalnischkies (kalnischk...@gmail.com) [120612 18:03]: You need to upgrade to support MultiArch, but you need MultiArch to upgrade… (beside, how would the detection for such a message look like?) We had discussed to export foreign-arch packages to the arches packages files at debconf. That would mean in this case that the amd64-packages file contains the i386-package wine-bin. That would allow to detect we need multi-arch packages easily (and avoid that people have to add all i386-packages to an amd64-system just to install wine-bin). In order to get that going, we would need to document in the release notes that certain packages either need to be put on hold prior to the upgrade in case they're installed or to upgrade apt, aptitude and dpkg first. Both had been done before. Andi -- 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/20120612203928.gb2...@mails.so.argh.org
Migration path for 'Multi-Arch:allowed' packages
Hi, We've been getting a few bug reports from users attempting to install multiarch wine who have yet to manually enable multiarch itself. Obviously that is a failure on their part, and is easily correctable. However, I wonder if we can't make such migrations a bit more straightforward? In particular, I filed a bug against dpkg requesting that it produce more informative error messages in these cases [0], but I wonder if a part of the solution shouldn't be more automated or at least presented at a higher level through apt/aptitude, etc? Also, limitations in the existing testing migration tools are making wine not considered for wheezy, since those tools don't check whether dependencies for 'Multi-Arch: allowed' packages are satisfied by packages on other architectures. Best wishes, Mike [0] http://bugs.debian.org/676822 [1] http://packages.qa.debian.org/w/wine.html -- 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/CANTw=mp3emp7idyp1dskpx3i4uytum-th42g3ufwwa5bjej...@mail.gmail.com
Re: Migration path for 'Multi-Arch:allowed' packages
On Mon, 2012-06-11 at 15:40 -0400, Michael Gilbert wrote: Also, limitations in the existing testing migration tools are making wine not considered for wheezy, since those tools don't check whether dependencies for 'Multi-Arch: allowed' packages are satisfied by packages on other architectures. What exactly would you expect britney to do here? Assume that if the dependencies are satisfiable on /any/ other architecture then everything's fine? I guess one could hard-code assumptions in to the (hypothetical) code like accept i386 packages for amd64 m-a: allowed, but I'm not sure that's the right solution. In any case, the eve of freeze doesn't seem like a great time to be making non-trivial changes to britney's concept of installability checking. YMMV, EOE. 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/1339445002.22084.14.ca...@jacala.jungle.funky-badger.org
