* Philip Brown <[email protected]> wrote: > I will also mention, given that Maciej gave the debian sharedlibs > policy (section 8.1) as a reference, if we abided by the WHOLE text of > that section. Again, my further notes on that, are at the bottom of > the wiki page.
When it comes to policy vs "when seen beneficial" in this case, I regard it as helpful to have as few exceptions and as much of a standard as possible. If the naming scheme is considered CAN and the release manager is to decide on a case by case basis whether the naming seems "beneficial" this somehow defeats the purpose of the (standardizing) naming policy in the first place and is prone to cause confusion (well, we have this guideline in place, but ...). No need to make it extra complicated. Maciej's checkpkg which is integrated into GAR even suggests the GAR directives for the lib package splitoff so the maintainer doesn't have to come up with them. > General comment I did not add into the wiki: I do not see having "more > packages" as a good in and of itself (and neither does Debian, as I > reference in the page). > If upgrading "libcups" -- what was previously a single package -- now > takes downloading and cycling through (pkgrm, pkgadd) **6** times... I > dont think this looks good to our users. To be honest, I have been using Debian for several years and only now (that we are talking about the library naming scheme) realized how the names of their libraries are constructed. To me - as a user - this has been and still is totally secondary as long as the application or service I want to use is working fine. The only time I wanted to explicitly pull in something library related is when I needed it for compilation purposes (the -dev package variants and these don't depend on SONAMES). Sebastian _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
