Re: Mass bugfiling in preparation for multiarch
Goswin von Brederlow goswin-...@web.de (17/03/2009): Aurelien Jarno aurel...@aurel32.net writes: I am interested in seeing the dpkg patch. The most current work should be on the multiarch alioth project. If you do work on something please add it there. http://alioth.debian.org/tracker/index.php?func=detailaid=310911group_id=30462atid=411196 It is not as complete as it once was but against the most recent source and with some previous mistakes corrected. I guess (at least in dpkg's case), having a git branch somewhere might help WRT possible inclusion, rather than a patch in an obscure ticket system? :) Mraw, KiBi. signature.asc Description: Digital signature
Re: Mass bugfiling in preparation for multiarch
Aurelien Jarno aurel...@aurel32.net writes: On Mon, Mar 16, 2009 at 12:11:35PM +0100, Goswin von Brederlow wrote: Hi, over the weekend I did some work on multiarch again and did notice some new and old problems when adding more libraries to my test set. Given that the problems are quite easily detectable I'm considering scanning all packages for their occurance and reporting bugs for them. In detail I'm looking for the following situations violating 'Policy 8.2 Shared library support files': [snip] Any objections to this? Note that most will be violations of a MUST directive of policy. If you want to get some more multiarch ennemies, this is clearly the way to go. The alternate method is to post a list to debian-devel, and when we have a basic multiarch support, you may start thinking about filling bugs. Not before. So we should just ignore blatant policy violation until the moment they do bite us in the ass? So we wait until the verry last moment when everything would be ready to use multiarch and then we freeze squeeze before package can be fixed to be multiarch compatible? And by the way. We had basic multiarch support before sarge. This is not before. This is after it has already killed multiarch for 2 stable releases. If we don't get things moving in parallel it will never be ready for squeeze either. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Mass bugfiling in preparation for multiarch
Hi Dne Tue, 17 Mar 2009 11:34:28 +0100 Goswin von Brederlow goswin-...@web.de napsal(a): So we should just ignore blatant policy violation until the moment they do bite us in the ass? So we wait until the verry last moment when everything would be ready to use multiarch and then we freeze squeeze before package can be fixed to be multiarch compatible? And by the way. We had basic multiarch support before sarge. This is not before. This is after it has already killed multiarch for 2 stable releases. If we don't get things moving in parallel it will never be ready for squeeze either. How about first providing list of affected packages (processed through dd-list)? I'm pretty sure that many issues will be fixed just after you point them out, just the maintainer was not aware of this problem. PS: This also looks to me like good candidate for lintian test, have you considered also this option? -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Mass bugfiling in preparation for multiarch
Goswin von Brederlow a écrit : Aurelien Jarno aurel...@aurel32.net writes: On Mon, Mar 16, 2009 at 12:11:35PM +0100, Goswin von Brederlow wrote: Hi, over the weekend I did some work on multiarch again and did notice some new and old problems when adding more libraries to my test set. Given that the problems are quite easily detectable I'm considering scanning all packages for their occurance and reporting bugs for them. In detail I'm looking for the following situations violating 'Policy 8.2 Shared library support files': [snip] Any objections to this? Note that most will be violations of a MUST directive of policy. If you want to get some more multiarch ennemies, this is clearly the way to go. The alternate method is to post a list to debian-devel, and when we have a basic multiarch support, you may start thinking about filling bugs. Not before. So we should just ignore blatant policy violation until the moment they do bite us in the ass? So we wait until the verry last moment when everything would be ready to use multiarch and then we freeze squeeze before package can be fixed to be multiarch compatible? No, the first step is to provide a list of affected package, just as explained in the developer reference. You should also discuss with ftpmaster, as such changes has been rejected by them, for example libc6 split into libc-bin. And by the way. We had basic multiarch support before sarge. This is not before. This is after it has already killed multiarch for 2 stable releases. If we don't get things moving in parallel it will never be ready for squeeze either. Yeah, we clearly don't have multiarch support because of libraries installing files in the wrong place. Not because we don't have toolchain/dpkg support. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Mass bugfiling in preparation for multiarch
Aurelien Jarno aurel...@aurel32.net writes: On Mon, Mar 16, 2009 at 03:40:53PM -0700, Russ Allbery wrote: Aurelien Jarno aurel...@aurel32.net writes: If you want to get some more multiarch ennemies, this is clearly the way to go. The alternate method is to post a list to debian-devel, and when we have a basic multiarch support, you may start thinking about filling bugs. Not before. Well, regardless of the benefits for multiarch, library packages containing binaries that don't change names with different SONAMEs violate a Policy must at present. So either they're RC bugs or Policy is wrong about the severity. It's a theoretical problem in libc6 in particular since the chances of libc6 changing SONAMEs again is low and there would be a lot of other work to have to do to deal with that apart from the binaries in /usr/bin, but the situation for other libraries is much more concrete. I've already filed an RC bug about this in one other package that I ran into. I think such bugs are fair game regardless of whether or not we're trying to implement multiarch (with the normal caveats about mass bug filing). If the file does change with SONAME, that's a different matter, and that part depends more on our multiarch direction. I will try to look for both cases but split the list into those that violate the MUST and those that are only a problem for multiarch. I'm not expecting so many of the later. Use of the SONAME looked rare in the small set I worked with so far. Still mass filling bugs is not the solution here. As it see seems we like policy and reference, let me quote the developer reference 7.2: Please use the programms dd-list and if appropriate whodepends (from the package devscripts) to generate a list of all affected packages, and include the output in your mail to debian-devel@lists.debian.org. That's what I suggested. Except you didn't say that. What you first wrote I read as Don't you dare file any bugs for any of them. Reading this mail it seems you more probably ment Lets generate a list first and then talk about it again.. Sorry for my strong first reply. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Mass bugfiling in preparation for multiarch
Aurelien Jarno aurel...@aurel32.net writes: Goswin von Brederlow a écrit : And by the way. We had basic multiarch support before sarge. This is not before. This is after it has already killed multiarch for 2 stable releases. If we don't get things moving in parallel it will never be ready for squeeze either. Yeah, we clearly don't have multiarch support because of libraries installing files in the wrong place. Not because we don't have toolchain/dpkg support. We had patches for binutils and dpkg. We also had patches for most essential packages. And everyone points the finger at someone else and says: Let them add their part first. Verry frustrating as you can imagine. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Mass bugfiling in preparation for multiarch
On Tue, Mar 17, 2009 at 07:48:18PM +0100, Goswin von Brederlow wrote: Aurelien Jarno aurel...@aurel32.net writes: Goswin von Brederlow a écrit : And by the way. We had basic multiarch support before sarge. This is not before. This is after it has already killed multiarch for 2 stable releases. If we don't get things moving in parallel it will never be ready for squeeze either. Yeah, we clearly don't have multiarch support because of libraries installing files in the wrong place. Not because we don't have toolchain/dpkg support. We had patches for binutils and dpkg. We also had patches for most essential packages. And everyone points the finger at someone else and says: Let them add their part first. Verry frustrating as you can imagine. I am interested in seeing the dpkg patch. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Mass bugfiling in preparation for multiarch
Aurelien Jarno aurel...@aurel32.net writes: On Tue, Mar 17, 2009 at 07:48:18PM +0100, Goswin von Brederlow wrote: Aurelien Jarno aurel...@aurel32.net writes: Goswin von Brederlow a écrit : And by the way. We had basic multiarch support before sarge. This is not before. This is after it has already killed multiarch for 2 stable releases. If we don't get things moving in parallel it will never be ready for squeeze either. Yeah, we clearly don't have multiarch support because of libraries installing files in the wrong place. Not because we don't have toolchain/dpkg support. We had patches for binutils and dpkg. We also had patches for most essential packages. And everyone points the finger at someone else and says: Let them add their part first. Verry frustrating as you can imagine. I am interested in seeing the dpkg patch. The most current work should be on the multiarch alioth project. If you do work on something please add it there. http://alioth.debian.org/tracker/index.php?func=detailaid=310911group_id=30462atid=411196 It is not as complete as it once was but against the most recent source and with some previous mistakes corrected. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Mass bugfiling in preparation for multiarch
Hi, over the weekend I did some work on multiarch again and did notice some new and old problems when adding more libraries to my test set. Given that the problems are quite easily detectable I'm considering scanning all packages for their occurance and reporting bugs for them. In detail I'm looking for the following situations violating 'Policy 8.2 Shared library support files': 1) Library packages that contain public binary ([/usr]/[s]bin/*) Policy 8.2 says: | If your package contains files whose names do not change with each | change in the library shared object version, you must not put them in | the shared library package. Otherwise, several versions of the shared | library cannot be installed at the same time without filename clashes, | making upgrades and transitions unnecessarily difficult. Example: libc6 contains /usr/sbin/zic, /usr/bin/getent and several more libc6 must be split into libc-bin and libc6 packages. 2) Library packages that contain conffiles First Policy 8.2. If the conffiles are not named in a way that changes with each soname change then this is a violation of a MUST directive. Example: libc6 conatins /etc/gai.conf Secondly even conffiles with unique names will be a problem for multiarch. The library package would be installed from i386 and amd64 resulting in 2 debs with the same conffile. Example: libgtk2.0-0 contains /etc/gtk-2.0/im-multipress.conf For this I want to file bugs (on top of violations of the MUST directive) requesting that either the conffile is split into a seperate package (say you already have a libfoo and foo-bin package) or made unique for the target: /etc/gtk-2.0-x86_64-linux-gnu/im-multipress.conf. 3) Library packages that contain shared files Policy 8.2 goes on to say this about shared files: | If the program or file is architecture independent, the | recommendation is for it to be placed in a subdirectory of | /usr/share instead, preferably under | /usr/share/package-name. Following the package-name naming | convention ensures that the file names change when the shared object | version changes. But the MUST directive of 8.2 still remains and packages not using a /usr/share/package-name but something more generic are in violation. Example: libasound2 contains /usr/share/alsa/alsa.conf libarts1c2a conatins /usr/share/man/man1/artsdsp.1.gz Again for multiarch this becomes more complicated. /usr/share/package-name will still cause a conflict between the i386 and amd64 flavour of a library package. For this I want to file bugs (again on top of the violations of the MUST directive) requesting that either the shared data is split out into libfoo-common packages or, in case of verry small files, moved out of shared into the multiarch library path: /usr/lib/x86_64-linux-gnu/package/. Example: libdirectfb-1.0-0 contains /usr/share/directfb-1.0.1/cursor.dat Any objections to this? Note that most will be violations of a MUST directive of policy. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Mass bugfiling in preparation for multiarch
Le lundi 16 mars 2009 à 12:11 +0100, Goswin von Brederlow a écrit : Example: libgtk2.0-0 contains /etc/gtk-2.0/im-multipress.conf For this I want to file bugs (on top of violations of the MUST directive) requesting that either the conffile is split into a seperate package (say you already have a libfoo and foo-bin package) or made unique for the target: /etc/gtk-2.0-x86_64-linux-gnu/im-multipress.conf. Insane. This file must, of course, be moved to libgtk2.0-common instead. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Mass bugfiling in preparation for multiarch
Josselin Mouette j...@debian.org writes: Le lundi 16 mars 2009 à 12:11 +0100, Goswin von Brederlow a écrit : Example: libgtk2.0-0 contains /etc/gtk-2.0/im-multipress.conf For this I want to file bugs (on top of violations of the MUST directive) requesting that either the conffile is split into a seperate package (say you already have a libfoo and foo-bin package) or made unique for the target: /etc/gtk-2.0-x86_64-linux-gnu/im-multipress.conf. Insane. This file must, of course, be moved to libgtk2.0-common instead. That depends on the contents of the file. In this example the file is architecture independent so duplicating it per target is stupid. In other cases there would be a list of available plugins for an application. And for every target triplet the list of plugins can differ. In those cases adding the triplet to either the dir or the filename makes sense. E.g. /etc/libfoo/plugins-x86_64-linux-gnu.d/ MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Mass bugfiling in preparation for multiarch
On Mon, Mar 16, 2009 at 12:11:35PM +0100, Goswin von Brederlow wrote: Hi, over the weekend I did some work on multiarch again and did notice some new and old problems when adding more libraries to my test set. Given that the problems are quite easily detectable I'm considering scanning all packages for their occurance and reporting bugs for them. In detail I'm looking for the following situations violating 'Policy 8.2 Shared library support files': [snip] Any objections to this? Note that most will be violations of a MUST directive of policy. If you want to get some more multiarch ennemies, this is clearly the way to go. The alternate method is to post a list to debian-devel, and when we have a basic multiarch support, you may start thinking about filling bugs. Not before. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Mass bugfiling in preparation for multiarch
Aurelien Jarno aurel...@aurel32.net writes: If you want to get some more multiarch ennemies, this is clearly the way to go. The alternate method is to post a list to debian-devel, and when we have a basic multiarch support, you may start thinking about filling bugs. Not before. Well, regardless of the benefits for multiarch, library packages containing binaries that don't change names with different SONAMEs violate a Policy must at present. So either they're RC bugs or Policy is wrong about the severity. It's a theoretical problem in libc6 in particular since the chances of libc6 changing SONAMEs again is low and there would be a lot of other work to have to do to deal with that apart from the binaries in /usr/bin, but the situation for other libraries is much more concrete. I've already filed an RC bug about this in one other package that I ran into. I think such bugs are fair game regardless of whether or not we're trying to implement multiarch (with the normal caveats about mass bug filing). If the file does change with SONAME, that's a different matter, and that part depends more on our multiarch direction. -- 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
Re: Mass bugfiling in preparation for multiarch
On Mon, Mar 16, 2009 at 03:40:53PM -0700, Russ Allbery wrote: Aurelien Jarno aurel...@aurel32.net writes: If you want to get some more multiarch ennemies, this is clearly the way to go. The alternate method is to post a list to debian-devel, and when we have a basic multiarch support, you may start thinking about filling bugs. Not before. Well, regardless of the benefits for multiarch, library packages containing binaries that don't change names with different SONAMEs violate a Policy must at present. So either they're RC bugs or Policy is wrong about the severity. It's a theoretical problem in libc6 in particular since the chances of libc6 changing SONAMEs again is low and there would be a lot of other work to have to do to deal with that apart from the binaries in /usr/bin, but the situation for other libraries is much more concrete. I've already filed an RC bug about this in one other package that I ran into. I think such bugs are fair game regardless of whether or not we're trying to implement multiarch (with the normal caveats about mass bug filing). If the file does change with SONAME, that's a different matter, and that part depends more on our multiarch direction. Still mass filling bugs is not the solution here. As it see seems we like policy and reference, let me quote the developer reference 7.2: Please use the programms dd-list and if appropriate whodepends (from the package devscripts) to generate a list of all affected packages, and include the output in your mail to debian-devel@lists.debian.org. That's what I suggested. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
