Re: is it a bug to not depend on a library package needed for some binary?
On Sunday 17 July 2005 10.14, Karl Chen wrote: Suppose package P contains files /usr/bin/B1 and /usr/bin/B2. B1 is the important program, and B2 is not as important. Is it OK for the declared package dependencies to not satisfy all the run-time shared library dependencies of B2? What if they are listed in Suggests? I have found many such packages. This is what Recommends: is for. I'd say a Suggests: is too weak (except if the helper program B2 is really, really unimportant - perhaps it should not be installed, or just put to /usr/share/doc/contrib or so? But as soon as B2 is something that actually is used by many people, a hard dependency would make sense. And, of course, for not-so-small B2, Goswin's suggestion to split it out into its own package makes sense, too. cheers -- vbi -- Today is Boomtime, the 56th day of Confusion in the YOLD 3171 pgpzjgiQHqyrp.pgp Description: PGP signature
Re: is it a bug to not depend on a library package needed for some binary?
On 2005-07-17 14:00 PDT, Matthew Woodcraft writes: Matthew There is a lot of discussion of this question in bug Matthew 119517 (where the conclusion reached was that this is Matthew sometimes ok). Wow, that was a long thread. Thanks for the pointer. I will file bugs if it there is no Recommends/Suggests and/or I can't find previous discussion of the issue. -- Karl 2005-07-18 12:46 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
is it a bug to not depend on a library package needed for some binary?
Suppose package P contains files /usr/bin/B1 and /usr/bin/B2. B1 is the important program, and B2 is not as important. Is it OK for the declared package dependencies to not satisfy all the run-time shared library dependencies of B2? What if they are listed in Suggests? I have found many such packages. -- Karl 2005-07-17 01:09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: is it a bug to not depend on a library package needed for some binary?
Karl Chen [EMAIL PROTECTED] writes: Suppose package P contains files /usr/bin/B1 and /usr/bin/B2. B1 is the important program, and B2 is not as important. Is it OK for the declared package dependencies to not satisfy all the run-time shared library dependencies of B2? What if they are listed in Suggests? I have found many such packages. Any examples? From my gut I would say thats a serious policy violation and if P can't depend on all libs it should be split into B1 and B2 packages and B1 suggest B2. If your examples are like B1 is a console program and B2 an X program and P doesn't want to pull in X for console users then splitting is the right thing to do. isdnutils would be example of having split due to this in the past. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: is it a bug to not depend on a library package needed for some binary?
2005/7/17, Goswin von Brederlow [EMAIL PROTECTED]: Karl Chen [EMAIL PROTECTED] writes: Suppose package P contains files /usr/bin/B1 and /usr/bin/B2. B1 is the important program, and B2 is not as important. Is it OK for the declared package dependencies to not satisfy all the run-time shared library dependencies of B2? What if they are listed in Suggests? I have found many such packages. Any examples? From my gut I would say thats a serious policy violation and if P can't depend on all libs it should be split into B1 and B2 packages and B1 suggest B2. If your examples are like B1 is a console program and B2 an X program and P doesn't want to pull in X for console users then splitting is the right thing to do. isdnutils would be example of having split due to this in the past. Let say, hypothetically, the maintainer made a script called /usr/bin/B2 which would check for the dependancies. If they're not present error out with a message please install program Y. If they are present, exec the original. Would this still be a policy violation?
Re: is it a bug to not depend on a library package needed for some binary?
Martijn van Oosterhout [EMAIL PROTECTED] writes: 2005/7/17, Goswin von Brederlow [EMAIL PROTECTED]: Karl Chen [EMAIL PROTECTED] writes: Suppose package P contains files /usr/bin/B1 and /usr/bin/B2. B1 is the important program, and B2 is not as important. Is it OK for the declared package dependencies to not satisfy all the run-time shared library dependencies of B2? What if they are listed in Suggests? I have found many such packages. Any examples? From my gut I would say thats a serious policy violation and if P can't depend on all libs it should be split into B1 and B2 packages and B1 suggest B2. If your examples are like B1 is a console program and B2 an X program and P doesn't want to pull in X for console users then splitting is the right thing to do. isdnutils would be example of having split due to this in the past. Let say, hypothetically, the maintainer made a script called /usr/bin/B2 which would check for the dependancies. If they're not present error out with a message please install program Y. If they are present, exec the original. Would this still be a policy violation? Probably not. But damn anoying. If it is a binary that just fails with a linker error then I would definetly report a bug. For a few K script on top of a say 1MB package splitting out that one script wouldn't be sensible. On the other hand if Y is a say 10K package itself depending on it as well doesn't hurt anyone, does it? It's all relative. If you can see a good reason to violate policy then even that can be allowed. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: is it a bug to not depend on a library package needed for some binary?
Karl Chen [EMAIL PROTECTED] wrote: Suppose package P contains files /usr/bin/B1 and /usr/bin/B2. B1 is the important program, and B2 is not as important. Is it OK for the declared package dependencies to not satisfy all the run-time shared library dependencies of B2? What if they are listed in Suggests? There is a lot of discussion of this question in bug 119517 (where the conclusion reached was that this is sometimes ok). -M- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: is it a bug to not depend on a library package needed for some binary?
On Sun, Jul 17, 2005 at 12:46:03PM +0200, Goswin von Brederlow wrote: If your examples are like B1 is a console program and B2 an X program and P doesn't want to pull in X for console users then splitting is the right thing to do. isdnutils would be example of having split due to this in the past. Policy (11.8.1) says that you should only split your package into X and non-X parts if it is higher priority than the X libraries (which are optional). isdnutils doesn't seem to qualify. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: is it a bug to not depend on a library package needed for some binary?
Hamish Moffatt [EMAIL PROTECTED] writes: On Sun, Jul 17, 2005 at 12:46:03PM +0200, Goswin von Brederlow wrote: If your examples are like B1 is a console program and B2 an X program and P doesn't want to pull in X for console users then splitting is the right thing to do. isdnutils would be example of having split due to this in the past. Policy (11.8.1) says that you should only split your package into X and non-X parts if it is higher priority than the X libraries (which are optional). isdnutils doesn't seem to qualify. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] People with their small headless isdn routers didn't feel like installing X on them just to be able to install isdn-utils at all. Enough people wished for a split and it was done. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: is it a bug to not depend on a library package needed for some binary?
On Mon, Jul 18, 2005 at 01:55:48AM +0200, Goswin von Brederlow wrote: Hamish Moffatt [EMAIL PROTECTED] writes: On Sun, Jul 17, 2005 at 12:46:03PM +0200, Goswin von Brederlow wrote: If your examples are like B1 is a console program and B2 an X program and P doesn't want to pull in X for console users then splitting is the right thing to do. isdnutils would be example of having split due to this in the past. Policy (11.8.1) says that you should only split your package into X and non-X parts if it is higher priority than the X libraries (which are optional). isdnutils doesn't seem to qualify. People with their small headless isdn routers didn't feel like installing X on them just to be able to install isdn-utils at all. Enough people wished for a split and it was done. The previous version of 11.8.1 was a bit less forgiving (changed in 1999). Anyway you are not obligated to install X but only some libraries. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
