Re: Packages violating policy 8.2
Thomas Girard [EMAIL PROTECTED] writes: Selon Goswin von Brederlow [EMAIL PROTECTED]: Debian policy says: | 8.2 Run-time support programs | | If your package has some run-time support programs which use the | shared library you must not put them in the shared library | package. If you do that then you won't be able to install several | versions of the shared library without getting filename clashes. | | Instead, either create another package for the runtime binaries | (this package might typically be named libraryname-runtime; note the | absence of the soversion in the package name), or if the development | package is small, include them in there. [...] several packages violate 8.2: [...] libciao0.4.7c2a Debian ACE+TAO maintainers libtao-orbsvcs1.4.7c2a Debian ACE+TAO maintainers I have started working on this issue[1], a major package split is planned for both TAO and CIAO. Thanks, Thomas [1] http://svn.debian.org/wsvn/pkg-ace/branches/pkg-split Thanks. Much appreciated. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Manoj Srivastava [EMAIL PROTECTED] writes: I would say, off hand, that section 8.2 is for people who want to provide a shared library for other packages, with a stable ABI, and a development package to facilitate linking to their library. There are certain hoops we must jump in order to not break packages whenever the share library package source changes. I agree with section 8.2 is for people who want to provide a shared library for other packages but not the rest. As soon as you have a cross source package dependency you will have upgrade problems if the shared library is not in a shared library package that follows 8.2. The big fat state reason why there is an 8.2. FHS 2.3: # /usr/lib includes object files, libraries, and internal binaries # that are not intended to be executed directly by users or shell # scripts. Thje FHS says nothing about packages, so as long as shared libs go into /usr/lib, I don't think the FHS sheds any other light on the topic. You forgot the next paragraph. An application in the FHS would be one or more packages in debian. But then again it says: _if_ you have a subdir then... It's non-obvious whether a given .so file is loaded with dlopen or loaded directly, but for example devscripts does the latter. As another example, I've recently made a program with three executables that share most of their code; quite an usual thing. To save space, the common parts are placed in a shared library (well, well, .dll ...) that resides in the program's private dir. On a FHS-compliant system, I can't think of any place to put such a library other than /usr/lib/$foo/; how is this different from the case of setools? Then any time you run the program, the loader needs to be told of the private directory, or you need to explicitly dlopen them. Why not put them in /usr/lib directly? especially if doing so otherwise would require major hacking of the upstream build system, and make Debian deviate from other distributions. I could add a subdir, and play with /etc/ld.so.conf in the maintainer scripts -- and deviate us from other distributions -- but to what end? How does it benefit the users if the libraries in question all live in /usr/lib rather than /usr/lib/setools ? Usualy that is done with rpath, as ugly as that is. Modifying /etc/ld.so.conf is never done. Setting LD_LIBRARY_PATH is another option as is using the full path in dlopen (though that is usualy only used on plugins). manoj MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
On 25 May 2006, Goswin von Brederlow uttered the following: Manoj Srivastava [EMAIL PROTECTED] writes: I would say, off hand, that section 8.2 is for people who want to provide a shared library for other packages, with a stable ABI, and a development package to facilitate linking to their library. There are certain hoops we must jump in order to not break packages whenever the share library package source changes. I agree with section 8.2 is for people who want to provide a shared library for other packages but not the rest. As soon as you have a cross source package dependency you will have upgrade problems if the shared library is not in a shared library package that follows 8.2. The big fat state reason why there is an 8.2. Umm, cross source package dependencies are not supported. The only such packages currently are all maintained by me, and yes, they all tend to be upgraded in lock step. I could add a subdir, and play with /etc/ld.so.conf in the maintainer scripts -- and deviate us from other distributions -- but to what end? How does it benefit the users if the libraries in question all live in /usr/lib rather than /usr/lib/setools ? Usualy that is done with rpath, as ugly as that is. Modifying /etc/ld.so.conf is never done. Setting LD_LIBRARY_PATH is another option as is using the full path in dlopen (though that is usualy only used on plugins). I am not dlopening these shared object. As to rpath, what is the rationale? Why must I do this, since the packaging already give package maintainers a strong hint that they should not link to these libraries? -- Give your very best today. Heaven knows it's little enough. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Manoj Srivastava [EMAIL PROTECTED] writes: On 25 May 2006, Goswin von Brederlow uttered the following: Manoj Srivastava [EMAIL PROTECTED] writes: I would say, off hand, that section 8.2 is for people who want to provide a shared library for other packages, with a stable ABI, and a development package to facilitate linking to their library. There are certain hoops we must jump in order to not break packages whenever the share library package source changes. I agree with section 8.2 is for people who want to provide a shared library for other packages but not the rest. As soon as you have a cross source package dependency you will have upgrade problems if the shared library is not in a shared library package that follows 8.2. The big fat state reason why there is an 8.2. Umm, cross source package dependencies are not supported. The only such packages currently are all maintained by me, and yes, they all tend to be upgraded in lock step. From your previous mail: |setools is in the list, and contains libraries that it uses | itself, but does not break it up into multiple installed | packages. Setools is moving rapidly rnough that I do not intend to | support multiple versions of the libraries until things stabilize a | bit. | |However, people do build binaries against these libraries, and | even have private packages, and I intend to support that. What is that if not a cross source package dependency? I could add a subdir, and play with /etc/ld.so.conf in the maintainer scripts -- and deviate us from other distributions -- but to what end? How does it benefit the users if the libraries in question all live in /usr/lib rather than /usr/lib/setools ? Usualy that is done with rpath, as ugly as that is. Modifying /etc/ld.so.conf is never done. Setting LD_LIBRARY_PATH is another option as is using the full path in dlopen (though that is usualy only used on plugins). I am not dlopening these shared object. As to rpath, what is the rationale? Why must I do this, since the packaging already give package maintainers a strong hint that they should not link to these libraries? Well, you are one of the authors of policy, you tell us the rational behind 10.2. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
On Tue, May 23, 2006 at 09:42:03PM -0500, Manoj Srivastava wrote: On 23 May 2006, Goswin von Brederlow stated: To me it sounds like you are. You provide a shared object file in a public place so other people can link their binaries against it. What else is a shared library? Does it matter if no package in Debian uses it but only other people? I think not. If you intention is to let others link against it then it is a shared library by all means. It is a shared library, and you are free to link with it -- but as a developer you must realize that your package may break on upgrade, since there is no shared library package, just a single combined setools package. I'm afraid that Goswin is right. If it's not a shared library package, it shouldn't have anything in /usr/lib; anything else belongs in /usr/lib/*/ or /usr/share/*/. Policy 10.2: | Shared object files (often .so files) that are not public libraries, | that is, they are not meant to be linked to by third party executables | (binaries of other packages), should be installed in subdirectories of | the /usr/lib directory. Such files are exempt from the rules that | govern ordinary shared libraries, except that they must not be | installed executable and should be stripped. Err, those a plugins, and one generally dlopens them, or otherwise manipulates the loader. It certainly does not apply. FHS 2.3: # /usr/lib includes object files, libraries, and internal binaries # that are not intended to be executed directly by users or shell # scripts. # # Applications may use a single subdirectory under /usr/lib. If an # application uses a subdirectory, all architecture-dependent data # exclusively used by the application must be placed within that # subdirectory. And indeed, most of files I find in /usr/lib/*/ on my system are not plugins but binary objects of any kind: * helper programs (most frequent case) * non-portable data (NetHack levels, etc) * firmware blobs * plugins * private shared libs ^^^ * scripts, headers, etc which differ between archs * object files for compilers It's non-obvious whether a given .so file is loaded with dlopen or loaded directly, but for example devscripts does the latter. As another example, I've recently made a program with three executables that share most of their code; quite an usual thing. To save space, the common parts are placed in a shared library (well, well, .dll ...) that resides in the program's private dir. On a FHS-compliant system, I can't think of any place to put such a library other than /usr/lib/$foo/; how is this different from the case of setools? I'm not sure if a nobody like me is the right person to correct Manoj, someone whose name is on the very policy package, but the issue seems to be pretty clear, at least to me... Cheers and schtuff, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Ganesan Rajagopal [EMAIL PROTECTED] writes: Manoj Srivastava [EMAIL PROTECTED] writes: I am not sure the sections need clarification, inasmuch as they do not really apply to setools. I might clarify that 8.2 is meant for packages that provide shared libraries for general use by other package developers, and it implies a certain level of assurance that the rug shall not be yanked out from under the aforementioned developers feet. Manoj, I have a package (ipsec-tools) which has a similar situation to setools and already has a bug filed for it (See #314981). I considered moving the concerned shared libraries into the plugin directory because these shared libraries were only for the ipsec-tools binaries and not for general use. That would need lots of unnecessary changes to the makefiles, probably fiddling with the dreaded RPATH etc. So, I think a clarification will be nice. Ganesan If the library is only internal then this falls under 10.2 I think, which is only a SHOULD diretive. The bug though sounds like Kilian Krause is asking you to make the library public so he can link against it. Do you ship a shlibs file? From the bug you aren't shipping a *.so link for linking which is correct for an internal library. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Goswin von Brederlow [EMAIL PROTECTED] writes: If the library is only internal then this falls under 10.2 I think, which is only a SHOULD diretive. You're right. This falls under 10.2 and as I mentioned before, moving the library to a subdirectory of /usr/lib is a pain. The bug though sounds like Kilian Krause is asking you to make the library public so he can link against it. Do you ship a shlibs file? From the bug you aren't shipping a *.so link for linking which is correct for an internal library. The library is an internal library and will not be made public. I'll tag the bug wont-fix. Thanks for the help. Ganesan -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
On 25 May 2006, Adam Borowski told this: On Tue, May 23, 2006 at 09:42:03PM -0500, Manoj Srivastava wrote: On 23 May 2006, Goswin von Brederlow stated: To me it sounds like you are. You provide a shared object file in a public place so other people can link their binaries against it. What else is a shared library? Does it matter if no package in Debian uses it but only other people? I think not. If you intention is to let others link against it then it is a shared library by all means. It is a shared library, and you are free to link with it -- but as a developer you must realize that your package may break on upgrade, since there is no shared library package, just a single combined setools package. I'm afraid that Goswin is right. If it's not a shared library package, it shouldn't have anything in /usr/lib; anything else belongs in /usr/lib/*/ or /usr/share/*/. Why is it that you think so? /usr/lib/ is for shared libraries, but I can't see anything that says only shared library packages contain shared libs. I would say, off hand, that section 8.2 is for people who want to provide a shared library for other packages, with a stable ABI, and a development package to facilitate linking to their library. There are certain hoops we must jump in order to not break packages whenever the share library package source changes. FHS 2.3: # /usr/lib includes object files, libraries, and internal binaries # that are not intended to be executed directly by users or shell # scripts. Thje FHS says nothing about packages, so as long as shared libs go into /usr/lib, I don't think the FHS sheds any other light on the topic. It's non-obvious whether a given .so file is loaded with dlopen or loaded directly, but for example devscripts does the latter. As another example, I've recently made a program with three executables that share most of their code; quite an usual thing. To save space, the common parts are placed in a shared library (well, well, .dll ...) that resides in the program's private dir. On a FHS-compliant system, I can't think of any place to put such a library other than /usr/lib/$foo/; how is this different from the case of setools? Then any time you run the program, the loader needs to be told of the private directory, or you need to explicitly dlopen them. Why not put them in /usr/lib directly? especially if doing so otherwise would require major hacking of the upstream build system, and make Debian deviate from other distributions. I could add a subdir, and play with /etc/ld.so.conf in the maintainer scripts -- and deviate us from other distributions -- but to what end? How does it benefit the users if the libraries in question all live in /usr/lib rather than /usr/lib/setools ? manoj -- Heisenberg may have slept here... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Manoj Srivastava [EMAIL PROTECTED] writes: I am not sure the sections need clarification, inasmuch as they do not really apply to setools. I might clarify that 8.2 is meant for packages that provide shared libraries for general use by other package developers, and it implies a certain level of assurance that the rug shall not be yanked out from under the aforementioned developers feet. Manoj, I have a package (ipsec-tools) which has a similar situation to setools and already has a bug filed for it (See #314981). I considered moving the concerned shared libraries into the plugin directory because these shared libraries were only for the ipsec-tools binaries and not for general use. That would need lots of unnecessary changes to the makefiles, probably fiddling with the dreaded RPATH etc. So, I think a clarification will be nice. Ganesan -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Selon Goswin von Brederlow [EMAIL PROTECTED]: Debian policy says: | 8.2 Run-time support programs | | If your package has some run-time support programs which use the | shared library you must not put them in the shared library | package. If you do that then you won't be able to install several | versions of the shared library without getting filename clashes. | | Instead, either create another package for the runtime binaries | (this package might typically be named libraryname-runtime; note the | absence of the soversion in the package name), or if the development | package is small, include them in there. [...] several packages violate 8.2: [...] libciao0.4.7c2a Debian ACE+TAO maintainers libtao-orbsvcs1.4.7c2aDebian ACE+TAO maintainers I have started working on this issue[1], a major package split is planned for both TAO and CIAO. Thanks, Thomas [1] http://svn.debian.org/wsvn/pkg-ace/branches/pkg-split -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Manoj Srivastava [EMAIL PROTECTED] writes: On 22 May 2006, Goswin von Brederlow stated: Manoj Srivastava [EMAIL PROTECTED] writes: On 22 May 2006, Goswin von Brederlow outgrape: I think that Policy 8.2 is fully applicable to your package then. It is a MUST directive so your unwillingness to allow multiple versions of your library to coexist does not affect the violation. I beg to differ. There is a rationale for the policy section: And if it where optional then it would read SHOULD. Or what is the difference between MUST and SHOULD if you can jsut choose to ignore both? The section in question is about shared library packages, but I am not actually creating a shared library package. Perhaps this needs clarification in policy. To me it sounds like you are. You provide a shared object file in a public place so other people can link their binaries against it. What else is a shared library? Does it matter if no package in Debian uses it but only other people? I think not. If you intention is to let others link against it then it is a shared library by all means. On a version upgrade the people that have their binaries linked against your lib will be unable to upgarde without removing those binaries first. The will have to work without them or with a chroot to even recompile for the new lib. Think about that. Following 8.2 you only have 2 choices: Split the package or provide only static libaries and live with the wasted space. Otherwise the packages is RC buggy. May I ask what is the underlying rationale for this judgement? My motivation is that not following 8.2 will make it impossible to convert the package to multiarch. For the rational of 8.2 itself you have to read policy and ask the people who wrote it. But I think it is pretty clear from the text: to be able to install multiple versions of the library for smooth upgrades. That person could well have been me, though I can't say I recall writing that. But the intent of the section is for shared library packages, and as such setools is not a shared library package. If you say those libraries are not public then policy 10.2 would seem to apply: Policy 10.2: | Shared object files (often .so files) that are not public libraries, | that is, they are not meant to be linked to by third party executables | (binaries of other packages), should be installed in subdirectories of | the /usr/lib directory. Such files are exempt from the rules that | govern ordinary shared libraries, except that they must not be | installed executable and should be stripped. Since you want to support linking by third party executables you don't quite fit the description of not public library. But well, lets keep one eye closed. Reading on you are violating a SHOULD directive. I agree that binary packages with *.so.* files can well fall under 10.2. Do you think your package fully does? I'll be happy to discuss what I need to do about multi-arch. In what way do you think splitting the package would work? Why is The same way it works for each and every other library package that is split in Debian. But I have no intention of supporting multiple versions of the libraries for setools, like I do for my other shared library packages which are indeed split up. facilitating private packages for people who are working with SELinux a bad thing, when people who actually build and use these packages are aware of the current state of flux of SELinux? It isn't a bad thing but you aren't doing it right (right as laid out in policy). Policy is not all infallible, not does it always apply. I think packages shipping libraries with relocatable code which explicitly do not support backwards compatibility nor multiple versions for the library in question, and do not split out library or -dev packages, are not covered by the rules designed for shared library packages. manoj It might be that that distinction is just missing from policy. So far it only has the two options: public shared library and not public library. Imho any third party linking against the library would mean it has to be (made) public. Feel free to draft a clarification to policy but I think 8.2 and 10.2 do cover all cases well enough. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
On 23 May 2006, Goswin von Brederlow stated: Manoj Srivastava [EMAIL PROTECTED] writes: On 22 May 2006, Goswin von Brederlow stated: Manoj Srivastava [EMAIL PROTECTED] writes: On 22 May 2006, Goswin von Brederlow outgrape: I think that Policy 8.2 is fully applicable to your package then. It is a MUST directive so your unwillingness to allow multiple versions of your library to coexist does not affect the violation. I beg to differ. There is a rationale for the policy section: And if it where optional then it would read SHOULD. Or what is the difference between MUST and SHOULD if you can jsut choose to ignore both? The section in question is about shared library packages, but I am not actually creating a shared library package. Perhaps this needs clarification in policy. To me it sounds like you are. You provide a shared object file in a public place so other people can link their binaries against it. What else is a shared library? Does it matter if no package in Debian uses it but only other people? I think not. If you intention is to let others link against it then it is a shared library by all means. It is a shared library, and you are free to link with it -- but as a developer you must realize that your package may break on upgrade, since there is no shared library package, just a single combined setools package. With that caveat, this is a convenience for people who are working on setools. On a version upgrade the people that have their binaries linked against your lib will be unable to upgarde without removing those binaries first. The will have to work without them or with a chroot to even recompile for the new lib. Think about that. I am. So if I build custom packages against these libraries, upgrades fail to install -- and then I force install and rebuild at a time of my chosing. Works quite well for me. Following 8.2 you only have 2 choices: Split the package or provide only static libaries and live with the wasted space. Otherwise the packages is RC buggy. May I ask what is the underlying rationale for this judgement? My motivation is that not following 8.2 will make it impossible to convert the package to multiarch. For the rational of 8.2 itself you have to read policy and ask the people who wrote it. But I think it is pretty clear from the text: to be able to install multiple versions of the library for smooth upgrades. That person could well have been me, though I can't say I recall writing that. But the intent of the section is for shared library packages, and as such setools is not a shared library package. If you say those libraries are not public then policy 10.2 would seem to apply: Policy 10.2: | Shared object files (often .so files) that are not public libraries, | that is, they are not meant to be linked to by third party executables | (binaries of other packages), should be installed in subdirectories of | the /usr/lib directory. Such files are exempt from the rules that | govern ordinary shared libraries, except that they must not be | installed executable and should be stripped. Err, those a plugins, and one generally dlopens them, or otherwise manipulates the loader. It certainly does not apply. Since you want to support linking by third party executables you don't quite fit the description of not public library. But well, lets keep one eye closed. Reading on you are violating a SHOULD directive. I am not supporting linking by third party executables. I am, however, allowing people who recognize the lack to backward compatibility to help out with the development of SELinux. I agree that binary packages with *.so.* files can well fall under 10.2. Do you think your package fully does? Nope. I'll be happy to discuss what I need to do about multi-arch. In what way do you think splitting the package would work? Why is The same way it works for each and every other library package that is split in Debian. But I have no intention of supporting multiple versions of the libraries for setools, like I do for my other shared library packages which are indeed split up. facilitating private packages for people who are working with SELinux a bad thing, when people who actually build and use these packages are aware of the current state of flux of SELinux? It isn't a bad thing but you aren't doing it right (right as laid out in policy). Policy is not all infallible, not does it always apply. I think packages shipping libraries with relocatable code which explicitly do not support backwards compatibility nor multiple versions for the library in question, and do not split out library or -dev packages, are not covered by the rules designed for shared library packages. manoj It might be that that distinction is just missing from policy. So far it only has the two options: public shared library and not public library. Imho
Re: Packages violating policy 8.2
On 19 May 2006, Goswin von Brederlow outgrape: setools is in the list, and contains libraries that it uses itself, but does not break it up into multiple installed packages. Setools is moving rapidly rnough that I do not intend to support multiple versions of the libraries until things stabilize a bit. However, people do build binaries against these libraries, and even have private packages, and I intend to support that. For some (or a lot?) packages the maintainer may claim that they don't contain public shared libraries, only package internal shared objects. Then why do you have shlib files [only spot checked for that]? Allows private packages to have proper dependencies. If no other package is supposed to link against your shared object then why not link it in static? Because multiple binaries in the package linking to the libraries do reduce the memory usage? If the library is only used for binary packages from the same source [which always get updated together] then why not put it in /usr/lib/package/ and make it not public? Again, this it to allow people who do follow selinux to create their own packages, with the caveat that these packages become unuseable as soon as new versions of setool are released. I believe that if you have a shared object in (/usr)/lib then policy 8.2 _always_ applies. No excuses. Policy 8.2 is also a requirement for multiarch. For multiarch this will not only give conflicts between different soversions of a library but also between different architectures of a library. setools is not a shared library package, per se. It is a package that provides tools for SELinux, and also happens to distribute some shared libraries the tools use, and does not want to play LC_CONFIG games. Unless there is some reason not to I plan to file RC bugs at least against the 53 packages containing lib in the package name. well, setools does not have lib in the name, so I guess this does not apply. manoj -- Once the toothpaste is out of the tube, it's hard to get it back in. H.R. Haldeman Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Manoj Srivastava [EMAIL PROTECTED] writes: On 19 May 2006, Goswin von Brederlow outgrape: setools is in the list, and contains libraries that it uses itself, but does not break it up into multiple installed packages. Setools is moving rapidly rnough that I do not intend to support multiple versions of the libraries until things stabilize a bit. However, people do build binaries against these libraries, and even have private packages, and I intend to support that. I think that Policy 8.2 is fully applicable to your package then. It is a MUST directive so your unwillingness to allow multiple versions of your library to coexist does not affect the violation. Following 8.2 you only have 2 choices: Split the package or provide only static libaries and live with the wasted space. Otherwise the packages is RC buggy. My 2c, Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
On 22 May 2006, Goswin von Brederlow outgrape: Manoj Srivastava [EMAIL PROTECTED] writes: On 19 May 2006, Goswin von Brederlow outgrape: setools is in the list, and contains libraries that it uses itself, but does not break it up into multiple installed packages. Setools is moving rapidly rnough that I do not intend to support multiple versions of the libraries until things stabilize a bit. However, people do build binaries against these libraries, and even have private packages, and I intend to support that. I think that Policy 8.2 is fully applicable to your package then. It is a MUST directive so your unwillingness to allow multiple versions of your library to coexist does not affect the violation. I beg to differ. There is a rationale for the policy section: that in general, shared library packages are meant to be long lived, and that packages linking to older versions of the library are supported. The policy then goes on to define how you achieve that. In this particular case, that is not supported, or even possible: SELinux packages move in lock step, and older versions of libraries and policy, and related tools and utilities would not work when the base packages are installed, in most cases. Following 8.2 you only have 2 choices: Split the package or provide only static libaries and live with the wasted space. Otherwise the packages is RC buggy. May I ask what is the underlying rationale for this judgement? In what way do you think splitting the package would work? Why is facilitating private packages for people who are working with SELinux a bad thing, when people who actually build and use these packages are aware of the current state of flux of SELinux? Remember the bit about foolish consistency for the sake of consistency and hobgoblins. I have reviewed this issue, and have decided tht the current single package approach is best, given the circumstances. msnoj -- Let us endeavor so to live that when we come to die even the undertaker will be sorry. -- Maek Twain, Pudd'nhead Wilson's Calendar Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Manoj Srivastava [EMAIL PROTECTED] writes: On 22 May 2006, Goswin von Brederlow outgrape: I think that Policy 8.2 is fully applicable to your package then. It is a MUST directive so your unwillingness to allow multiple versions of your library to coexist does not affect the violation. I beg to differ. There is a rationale for the policy section: And if it where optional then it would read SHOULD. Or what is the difference between MUST and SHOULD if you can jsut choose to ignore both? Following 8.2 you only have 2 choices: Split the package or provide only static libaries and live with the wasted space. Otherwise the packages is RC buggy. May I ask what is the underlying rationale for this judgement? My motivation is that not following 8.2 will make it impossible to convert the package to multiarch. For the rational of 8.2 itself you have to read policy and ask the people who wrote it. But I think it is pretty clear from the text: to be able to install multiple versions of the library for smooth upgrades. In what way do you think splitting the package would work? Why is The same way it works for each and every other library package that is split in Debian. facilitating private packages for people who are working with SELinux a bad thing, when people who actually build and use these packages are aware of the current state of flux of SELinux? It isn't a bad thing but you aren't doing it right (right as laid out in policy). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
On 22 May 2006, Goswin von Brederlow stated: Manoj Srivastava [EMAIL PROTECTED] writes: On 22 May 2006, Goswin von Brederlow outgrape: I think that Policy 8.2 is fully applicable to your package then. It is a MUST directive so your unwillingness to allow multiple versions of your library to coexist does not affect the violation. I beg to differ. There is a rationale for the policy section: And if it where optional then it would read SHOULD. Or what is the difference between MUST and SHOULD if you can jsut choose to ignore both? The section in question is about shared library packages, but I am not actually creating a shared library package. Perhaps this needs clarification in policy. Following 8.2 you only have 2 choices: Split the package or provide only static libaries and live with the wasted space. Otherwise the packages is RC buggy. May I ask what is the underlying rationale for this judgement? My motivation is that not following 8.2 will make it impossible to convert the package to multiarch. For the rational of 8.2 itself you have to read policy and ask the people who wrote it. But I think it is pretty clear from the text: to be able to install multiple versions of the library for smooth upgrades. That person could well have been me, though I can't say I recall writing that. But the intent of the section is for shared library packages, and as such setools is not a shared library package. I'll be happy to discuss what I need to do about multi-arch. In what way do you think splitting the package would work? Why is The same way it works for each and every other library package that is split in Debian. But I have no intention of supporting multiple versions of the libraries for setools, like I do for my other shared library packages which are indeed split up. facilitating private packages for people who are working with SELinux a bad thing, when people who actually build and use these packages are aware of the current state of flux of SELinux? It isn't a bad thing but you aren't doing it right (right as laid out in policy). Policy is not all infallible, not does it always apply. I think packages shipping libraries with relocatable code which explicitly do not support backwards compatibility nor multiple versions for the library in question, and do not split out library or -dev packages, are not covered by the rules designed for shared library packages. manoj -- Machine-Independent, adj.: Does not run on any existing machine. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
On 5/21/06, Goswin von Brederlow [EMAIL PROTECTED] wrote: For multiarch this will be an inconvenience though as people might want to install both 32bit and 64bit of a -dev package. For such small scripts spliting them into extra packages seems wrong but then you have to use alternatives or similar to avoid conflicts. Hmm, if a program to be compiled requires libfoo and libbar, and the user has installed libfoo32-dev and libbar64-dev, where is the error going to be picked up? Are the -dev package actually architecture sensetive? I'd suggest pkgconfig could be used to fix this, except that the --libs produces too much rubbish to be truly useful (see Bug#340904). But if it worked correctly, you could add a --arch flags there to ensure you get the right version. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Packages violating policy 8.2
Martijn van Oosterhout [EMAIL PROTECTED] writes: On 5/21/06, Goswin von Brederlow [EMAIL PROTECTED] wrote: For multiarch this will be an inconvenience though as people might want to install both 32bit and 64bit of a -dev package. For such small scripts spliting them into extra packages seems wrong but then you have to use alternatives or similar to avoid conflicts. Hmm, if a program to be compiled requires libfoo and libbar, and the user has installed libfoo32-dev and libbar64-dev, where is the error Under multiarch packages are not renamed. There is libfoo-dev i386 and libfoo-dev amd64. Hopefully they are coinstallable. For core libraries like libc6, zlib, ... this will be pretty much a requirement. going to be picked up? Are the -dev package actually architecture sensetive? Every -dev package contains the libfoobar.so - libfoobar.so.X.Y.Z link. Under multiarch they would be in the architecture specific library directory and thereby not architecture independent. So -dev can not be architecture all. Further, so that one can install both the 32bit and 64bit -dev package it has to set Multi-Arch: yes, which automaticaly means any depends on it has to match the ABI. If installation of both packages is not possible then the Multi-Arch tag has to be omited, which also causes the ABI to be matched. A libblub-dev with Depends: libfoo-dev, libbar-dev then automatically pulls in the same ABI for those 2 packages as it has itself ensuring that they fit. Same would go for Build-Depends (pull in the systems native architecture). I'd suggest pkgconfig could be used to fix this, except that the --libs produces too much rubbish to be truly useful (see Bug#340904). But if it worked correctly, you could add a --arch flags there to ensure you get the right version. pkgconfig currently has no multiarch support. The *.pc files are architecture dependent and will have to be moved into multiarch directories. But then how will pkgconfig know which one to use? It might have to use and merge all of them creating even more rubbish. This is one of the unsolved problems. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Goswin von Brederlow [EMAIL PROTECTED] writes: Hi, Debian policy says: | 8.2 Run-time support programs | | If your package has some run-time support programs which use the | shared library you must not put them in the shared library | package. If you do that then you won't be able to install several | versions of the shared library without getting filename clashes. | | Instead, either create another package for the runtime binaries | (this package might typically be named libraryname-runtime; note the | absence of the soversion in the package name), or if the development | package is small, include them in there. After seeing several packages that violate 8.2 I set out to find out how common that is: What about runtime support programs whose purpose is to print information for use in autoconf tests belonging to other programs which want to use the library? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: Hi, Debian policy says: | 8.2 Run-time support programs | | If your package has some run-time support programs which use the | shared library you must not put them in the shared library | package. If you do that then you won't be able to install several | versions of the shared library without getting filename clashes. | | Instead, either create another package for the runtime binaries | (this package might typically be named libraryname-runtime; note the | absence of the soversion in the package name), or if the development | package is small, include them in there. After seeing several packages that violate 8.2 I set out to find out how common that is: What about runtime support programs whose purpose is to print information for use in autoconf tests belonging to other programs which want to use the library? I would call those compile-time support programs and as the name indicates they should be in the -dev package. I filed a bug against policy clarifying the or if the development package is small, include them in there. to cover that meaning. A foobar-config program to get the right CFLAGS and LDFLAGS certainly does not need to be present without the header files. For multiarch this will be an inconvenience though as people might want to install both 32bit and 64bit of a -dev package. For such small scripts spliting them into extra packages seems wrong but then you have to use alternatives or similar to avoid conflicts. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Goswin von Brederlow wrote: Hi, Debian policy says: | 8.2 Run-time support programs | | If your package has some run-time support programs which use the | shared library you must not put them in the shared library | package. If you do that then you won't be able to install several | versions of the shared library without getting filename clashes. | | Instead, either create another package for the runtime binaries | (this package might typically be named libraryname-runtime; note the | absence of the soversion in the package name), or if the development | package is small, include them in there. [snip] For some (or a lot?) packages the maintainer may claim that they don't contain public shared libraries, only package internal shared objects. Then why do you have shlib files [only spot checked for that]? Have you verified which packages ship an shlib and which not? If no other package is supposed to link against your shared object then why not link it in static? Because it does not work? If the library is only used for binary packages from the same source [which always get updated together] then why not put it in /usr/lib/package/ and make it not public? The problem is that it is not a default search path for the linker. And adding an rpath would simply violate the policy. I believe that if you have a shared object in (/usr)/lib then policy 8.2 _always_ applies. No excuses. Policy 8.2 is also a requirement for multiarch. For multiarch this will not only give conflicts between different soversions of a library but also between different architectures of a library. Maybe we can change the policy for those packages. I don't see why this could be a problem for multiarch. The library is only used by the binary which is the same package, so they are always in sync. Unless there is some reason not to I plan to file RC bugs at least against the 53 packages containing lib in the package name. Please see with the release team before doing that. libc6 GNU Libc Maintainers debian-glibc@lists.debian.org For this one, please talk with the ftpmasters. Such a change has already been done, but rejected from the NEW queue. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Re: Goswin von Brederlow 2006-05-19 [EMAIL PROTECTED] The line below looks for all packages with a *.so.* file in (/usr)/lib and a file in (/usr)/bin. The assumption is that anything with a *.so.* file in the system library dirs is a library package and those may not have files in (/usr)/bin. sdate Christoph Berg [EMAIL PROTECTED] Bogus. (sdate is a fakeroot fork and needs a .so in /usr/lib/ for technical reasons.) Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Aurelien Jarno [EMAIL PROTECTED] wrote: libc6 GNU Libc Maintainers debian-glibc@lists.debian.org For this one, please talk with the ftpmasters. Such a change has already been done, but rejected from the NEW queue. Can you quote the reasons? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Packages violating policy 8.2
Frank Küster wrote: Aurelien Jarno [EMAIL PROTECTED] wrote: libc6 GNU Libc Maintainers debian-glibc@lists.debian.org For this one, please talk with the ftpmasters. Such a change has already been done, but rejected from the NEW queue. Can you quote the reasons? Yes, please see: http://lists.debian.org/debian-glibc/2006/04/msg00199.html -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Aurelien Jarno [EMAIL PROTECTED] wrote: Frank Küster wrote: Aurelien Jarno [EMAIL PROTECTED] wrote: libc6 GNU Libc Maintainers debian-glibc@lists.debian.org For this one, please talk with the ftpmasters. Such a change has already been done, but rejected from the NEW queue. Can you quote the reasons? Yes, please see: http://lists.debian.org/debian-glibc/2006/04/msg00199.html Ah, thanks, I remember. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Packages violating policy 8.2
Aurelien Jarno [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Hi, Debian policy says: | 8.2 Run-time support programs | | If your package has some run-time support programs which use the | shared library you must not put them in the shared library | package. If you do that then you won't be able to install several | versions of the shared library without getting filename clashes. | | Instead, either create another package for the runtime binaries | (this package might typically be named libraryname-runtime; note the | absence of the soversion in the package name), or if the development | package is small, include them in there. [snip] For some (or a lot?) packages the maintainer may claim that they don't contain public shared libraries, only package internal shared objects. Then why do you have shlib files [only spot checked for that]? Have you verified which packages ship an shlib and which not? As I said I only spot checked for the shlib files. If no other package is supposed to link against your shared object then why not link it in static? Because it does not work? You have the source, you are compiling it. Is it beyond you to change it to static linking? If the library is only used for binary packages from the same source [which always get updated together] then why not put it in /usr/lib/package/ and make it not public? The problem is that it is not a default search path for the linker. And adding an rpath would simply violate the policy. Policy 10.2: | Shared object files (often .so files) that are not public libraries, | that is, they are not meant to be linked to by third party | executables (binaries of other packages), should be installed in | subdirectories of the /usr/lib directory. Such files are exempt from | the rules that govern ordinary shared libraries, except that they | must not be installed executable and should be stripped.[57] Yes, that requires the use of rpath. But policy does not forbid that for non system library dirs [it would be a contradiction to 10.2]. I believe that if you have a shared object in (/usr)/lib then policy 8.2 _always_ applies. No excuses. Policy 8.2 is also a requirement for multiarch. For multiarch this will not only give conflicts between different soversions of a library but also between different architectures of a library. Maybe we can change the policy for those packages. I don't see why this could be a problem for multiarch. The library is only used by the binary which is the same package, so they are always in sync. libfoo:i386 contains /usr/bin/foo /usr/i486-linux-gnu/lib/libfoo.so.0 libfoo:amd64 contains /usr/bin/foo /usr/x86_64-linux-gnu/lib/libfoo.so.0 When both get installed dpkg will complain about trying to overwrite /usr/bin/foo. Unless there is some reason not to I plan to file RC bugs at least against the 53 packages containing lib in the package name. Please see with the release team before doing that. Do you think they want to wave an exception to 8.2 for etch? It isn't that big of a deal to fix this. libc6 GNU Libc Maintainers debian-glibc@lists.debian.org For this one, please talk with the ftpmasters. Such a change has already been done, but rejected from the NEW queue. With the reason that splitting essential packages has to be discussed first. That has been done now for libc6 and has to happen e.g. for apt. I agree that this will need extra care for essential packages but they still violate policy. The bug remains and I hope ftp-master can be convinced to abide by policy too. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Christoph Berg [EMAIL PROTECTED] writes: Re: Goswin von Brederlow 2006-05-19 [EMAIL PROTECTED] The line below looks for all packages with a *.so.* file in (/usr)/lib and a file in (/usr)/bin. The assumption is that anything with a *.so.* file in the system library dirs is a library package and those may not have files in (/usr)/bin. sdate Christoph Berg [EMAIL PROTECTED] Bogus. (sdate is a fakeroot fork and needs a .so in /usr/lib/ for technical reasons.) What reasons would that be? [EMAIL PROTECTED]:~ftp/debian% dpkg -c pool/main/f/fakeroot/fakeroot_1.5.8_i386.deb | grep \(bin\|lib\) drwxr-xr-x root/root 0 2006-03-17 01:11:32 ./usr/bin/ -rwxr-xr-x root/root 3072 2006-03-17 01:11:01 ./usr/bin/fakeroot-tcp -rwxr-xr-x root/root 18088 2006-03-17 01:11:32 ./usr/bin/faked-tcp -rwxr-xr-x root/root 3076 2006-03-17 01:11:02 ./usr/bin/fakeroot-sysv -rwxr-xr-x root/root 13972 2006-03-17 01:11:32 ./usr/bin/faked-sysv drwxr-xr-x root/root 0 2006-03-17 01:11:32 ./usr/lib/ drwxr-xr-x root/root 0 2006-03-17 01:11:32 ./usr/lib/libfakeroot/ -rwxr-xr-x root/root 23684 2006-03-17 01:11:32 ./usr/lib/libfakeroot/libfakeroot-tcp.so -rwxr-xr-x root/root 22720 2006-03-17 01:11:32 ./usr/lib/libfakeroot/libfakeroot-sysv.so -rwSr--r-- root/root 2656 2006-03-17 01:11:32 ./usr/lib/libfakeroot-tcp.so -rwSr--r-- root/root 2656 2006-03-17 01:11:32 ./usr/lib/libfakeroot-sysv.so drwxr-xr-x root/root 0 2006-03-17 01:11:29 ./usr/lib64/ drwxr-xr-x root/root 0 2006-03-17 01:11:32 ./usr/lib64/libfakeroot/ -rwxr-xr-x root/root 33728 2006-03-17 01:11:32 ./usr/lib64/libfakeroot/libfakeroot-tcp.so -rwxr-xr-x root/root 32584 2006-03-17 01:11:32 ./usr/lib64/libfakeroot/libfakeroot-sysv.so Fakeroot itself didn't need it so why should a fork need it all of a sudden? Fakeroot is policy 8.2 compliant. The sdate package looks odd to me anyway: -rw-r--r-- root/root 5112 2006-04-25 16:35:40 ./usr/lib/libsdate/libsdate.so.0.0.1 -rw-r--r-- root/root 819 2006-04-25 16:35:34 ./usr/lib/libsdate/libsdate.la -rw-r--r-- root/root 3418 2006-04-25 16:35:40 ./usr/lib/libsdate/libsdate.a -rwSr--r-- root/root 2640 2006-04-25 16:35:40 ./usr/lib/libsdate.so.0.0.1 -rw-r--r-- root/root 810 2006-04-25 16:35:35 ./usr/lib/libsdate.la -rw-r--r-- root/root 866 2006-04-25 16:35:40 ./usr/lib/libsdate.a Why do you have a public and non-public version of the library? The package description says sdate uses LD_PRELOAD. All you need on top of that is to set LD_LIBRARY_PATH to include the /usr/lib*/libsdate/ directories and you can use non-public libs only. Just like fakeroot. Also please consider providing both 32 and 64bit flavours of the libraries. Just like fakeroot. Christoph MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Goswin von Brederlow wrote: Aurelien Jarno [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Hi, Debian policy says: | 8.2 Run-time support programs | | If your package has some run-time support programs which use the | shared library you must not put them in the shared library | package. If you do that then you won't be able to install several | versions of the shared library without getting filename clashes. | | Instead, either create another package for the runtime binaries | (this package might typically be named libraryname-runtime; note the | absence of the soversion in the package name), or if the development | package is small, include them in there. If no other package is supposed to link against your shared object then why not link it in static? Because it does not work? You have the source, you are compiling it. Is it beyond you to change it to static linking? I already tried that, but the resulting binary does not work If the library is only used for binary packages from the same source [which always get updated together] then why not put it in /usr/lib/package/ and make it not public? The problem is that it is not a default search path for the linker. And adding an rpath would simply violate the policy. Policy 10.2: | Shared object files (often .so files) that are not public libraries, | that is, they are not meant to be linked to by third party | executables (binaries of other packages), should be installed in | subdirectories of the /usr/lib directory. Such files are exempt from | the rules that govern ordinary shared libraries, except that they | must not be installed executable and should be stripped.[57] Yes, that requires the use of rpath. But policy does not forbid that for non system library dirs [it would be a contradiction to 10.2]. I believe that if you have a shared object in (/usr)/lib then policy 8.2 _always_ applies. No excuses. Policy 8.2 is also a requirement for multiarch. For multiarch this will not only give conflicts between different soversions of a library but also between different architectures of a library. Maybe we can change the policy for those packages. I don't see why this could be a problem for multiarch. The library is only used by the binary which is the same package, so they are always in sync. libfoo:i386 contains /usr/bin/foo /usr/i486-linux-gnu/lib/libfoo.so.0 libfoo:amd64 contains /usr/bin/foo /usr/x86_64-linux-gnu/lib/libfoo.so.0 When both get installed dpkg will complain about trying to overwrite /usr/bin/foo. Agreed, but we are speaking of binaries shipping private libraries, and I don't see why you want to install both version of it. Anyway other packages containing binaries and not libraries does not allow that. Unless there is some reason not to I plan to file RC bugs at least against the 53 packages containing lib in the package name. Please see with the release team before doing that. Do you think they want to wave an exception to 8.2 for etch? It isn't that big of a deal to fix this. Well, until know all my attempt do to static linking failed, the resulting binary was not usable. But patches are welcome. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Aurelien Jarno [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Aurelien Jarno [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Hi, Debian policy says: | 8.2 Run-time support programs | | If your package has some run-time support programs which use the | shared library you must not put them in the shared library | package. If you do that then you won't be able to install several | versions of the shared library without getting filename clashes. | | Instead, either create another package for the runtime binaries | (this package might typically be named libraryname-runtime; note the | absence of the soversion in the package name), or if the development | package is small, include them in there. If no other package is supposed to link against your shared object then why not link it in static? Because it does not work? You have the source, you are compiling it. Is it beyond you to change it to static linking? I already tried that, but the resulting binary does not work Oh, what package is that? I'm assuming kwave as that is the only one with your email. If the library is only used for binary packages from the same source [which always get updated together] then why not put it in /usr/lib/package/ and make it not public? The problem is that it is not a default search path for the linker. And adding an rpath would simply violate the policy. Policy 10.2: | Shared object files (often .so files) that are not public libraries, | that is, they are not meant to be linked to by third party | executables (binaries of other packages), should be installed in | subdirectories of the /usr/lib directory. Such files are exempt from | the rules that govern ordinary shared libraries, except that they | must not be installed executable and should be stripped.[57] Yes, that requires the use of rpath. But policy does not forbid that for non system library dirs [it would be a contradiction to 10.2]. I believe that if you have a shared object in (/usr)/lib then policy 8.2 _always_ applies. No excuses. Policy 8.2 is also a requirement for multiarch. For multiarch this will not only give conflicts between different soversions of a library but also between different architectures of a library. Maybe we can change the policy for those packages. I don't see why this could be a problem for multiarch. The library is only used by the binary which is the same package, so they are always in sync. libfoo:i386 contains /usr/bin/foo /usr/i486-linux-gnu/lib/libfoo.so.0 libfoo:amd64 contains /usr/bin/foo /usr/x86_64-linux-gnu/lib/libfoo.so.0 When both get installed dpkg will complain about trying to overwrite /usr/bin/foo. Agreed, but we are speaking of binaries shipping private libraries, and I don't see why you want to install both version of it. Anyway other packages containing binaries and not libraries does not allow that. That might be the case for the packages that only have private share libraries in public places. Reading policy 10.2 again it seems to indicate that it exempts private libraries from 8.2. Is that correct? In that case all but ~50 packages on the list might be ok, only violating a should directive and they simply won't be multiarch capable (and don't need to in all likelyhood). Unless there is some reason not to I plan to file RC bugs at least against the 53 packages containing lib in the package name. Please see with the release team before doing that. Do you think they want to wave an exception to 8.2 for etch? It isn't that big of a deal to fix this. Well, until know all my attempt do to static linking failed, the resulting binary was not usable. But patches are welcome. If your package is not named libsomething you don't have to fear a bugreport from me. But it would be intresting to see just why it fails when linked static anyway. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
On Fri, 2006-05-19 at 18:44 +0200, Goswin von Brederlow wrote: Debian policy says: | 8.2 Run-time support programs | | If your package has some run-time support programs which use the | shared library you must not put them in the shared library | package. If you do that then you won't be able to install several | versions of the shared library without getting filename clashes. | | Instead, either create another package for the runtime binaries | (this package might typically be named libraryname-runtime; note the | absence of the soversion in the package name), or if the development | package is small, include them in there. [snip] Package Maintainer - qprof Al Stone [EMAIL PROTECTED] Then why do you have shlib files [only spot checked for that]? For qprof, because that's how it works; it uses a shared library plus LD_PRELOAD so it can capture performance information without changing an application. The only run-time binary apart from the .so is a script that sets LD_PRELOAD for you. If no other package is supposed to link against your shared object then why not link it in static? Because then you can't use LD_PRELOAD and the package won't work -- qprof is designed so you can collect performance data without modifying your program. If you have to link in the library to your application to collect performance data, you've violated the basic premise of the package. If the library is only used for binary packages from the same source [which always get updated together] then why not put it in /usr/lib/package/ and make it not public? This could be done for the qprof package. I'm not sure that qualifies as an RC bug, though. Policy 8.2 never mentions that as a possibility; it is perhaps implicit in the description, but not very obvious. I believe that if you have a shared object in (/usr)/lib then policy 8.2 _always_ applies. No excuses. Policy 8.2 is also a requirement for multiarch. For multiarch this will not only give conflicts between different soversions of a library but also between different architectures of a library. I can see how you came to that belief; having read 8.2 several times before this, that was not an obvious conclusion to me. Do you have any suggestions for ways to make the policy section clearer? I haven't thought this through enough yet to make a suggestion for improvement... -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux RD Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
On Fri, May 19, 2006 at 07:56:54PM +0200, Goswin von Brederlow wrote: Aurelien Jarno [EMAIL PROTECTED] writes: I don't see why this could be a problem for multiarch. The library is only used by the binary which is the same package, so they are always in sync. libfoo:i386 contains /usr/bin/foo /usr/i486-linux-gnu/lib/libfoo.so.0 libfoo:amd64 contains /usr/bin/foo /usr/x86_64-linux-gnu/lib/libfoo.so.0 When both get installed dpkg will complain about trying to overwrite /usr/bin/foo. Surely you're just pushing this out to libfoo-bin:i386 contains /usr/bin/foo and likewise libfoo-bin:amd64 and getting the conflict there. How do you resolve that? Simon -- ... You still here Basil? - Sybil No, I went a couple of minutes ago, dear, but I expect I'll be back soon. - Basil, Fawlty Towers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Al Stone [EMAIL PROTECTED] writes: If the library is only used for binary packages from the same source [which always get updated together] then why not put it in /usr/lib/package/ and make it not public? This could be done for the qprof package. I'm not sure that qualifies as an RC bug, though. Policy 8.2 never mentions that as a possibility; it is perhaps implicit in the description, but not very obvious. I believe that if you have a shared object in (/usr)/lib then policy 8.2 _always_ applies. No excuses. Policy 8.2 is also a requirement for multiarch. For multiarch this will not only give conflicts between different soversions of a library but also between different architectures of a library. I can see how you came to that belief; having read 8.2 several times before this, that was not an obvious conclusion to me. Do you have any suggestions for ways to make the policy section clearer? I haven't thought this through enough yet to make a suggestion for improvement... Somewhere else in this thread I quoted Policy 10.2. After reading them both a couple of times I think 10.2 applies for the case here and other binary packages that also have a *.so.* file. That reduces the problem to a SHOULD directive. So I think I have to retract my _always_. I can indeed suggest an improvement if 10.2 is ment for these cases. 8.2 should have a reference to 10.2 noting the exemption. Do 2 DDs second that? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages violating policy 8.2
Simon Huggins [EMAIL PROTECTED] writes: On Fri, May 19, 2006 at 07:56:54PM +0200, Goswin von Brederlow wrote: Aurelien Jarno [EMAIL PROTECTED] writes: I don't see why this could be a problem for multiarch. The library is only used by the binary which is the same package, so they are always in sync. libfoo:i386 contains /usr/bin/foo /usr/i486-linux-gnu/lib/libfoo.so.0 libfoo:amd64 contains /usr/bin/foo /usr/x86_64-linux-gnu/lib/libfoo.so.0 When both get installed dpkg will complain about trying to overwrite /usr/bin/foo. Surely you're just pushing this out to libfoo-bin:i386 contains /usr/bin/foo and likewise libfoo-bin:amd64 and getting the conflict there. How do you resolve that? Simon You would be able to install libfoo:i386, libfoo:amd64 and either libfoo-bin:i386 or libfoo-bin:amd64. Now if you have packages bar and baz that Depend: libfoo you can install both bar:i386 and baz:amd64. Without the split package this would not be possible. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
