No dia 16 de Novembro de 2010 00:20, Philip Brown <[email protected]> escreveu: > This is starting off a fresh thread, on the proposal being suggested > around naming of packages, that have shared libraries in them. > > Maciej was kind enough to write up a web page for it, here: > > http://wiki.opencsw.org/packaging-shared-libraries > > I have made some very minor updates to it, and corrected the naming > length "32" to "29" . > > I then added some areas of concern that I have, to the bottom of the page. > > I was originally going to quote them here, but they have become rather long > :-/ > So perhaps they are better read in the full context of the wiki page, above. > > > 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. > > > 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).
It can be viewed as both good and bad, depending on the context. We can remove this point if you wish. > 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. Granted that 6 packages will take slightly longer to install, I don't see why is that a problem. > What to do when a software package has its common name as "libxyz", and then > also contains a "libxyz.so.#" ? You'd follow the recommendation and have CSWlibxyz# with the library, CSWlibxyz-devel with headers and the .so file, and if there's anything left, CSWlibxyz-doc, etc. > People will usually expect to find the package by simple name. Do we provide > a ghost "libxyz" package that depends on the longer named one? Or expect that > our users will educate themselves (usually a losing proposition) They will probably do something like "pkgutil -a libxyz" and find out the package names. > What to do when a software package is primarily a library, but is more > commonly known by a shorter name? EG: "ldns", which technically is short for > "libdns", and mostly just provides a "libdns", but its software name is > specifically "ldns" NOT "libldns". :: http://www.nlnetlabs.nl/projects/ldns/ Follow the recommendation: CSWldns-devel with the header files CSWlibldns1 with /opt/csw/lib/libldns.so.1 CSWldns(-.*)? if there's anything left (docs, tools, etc) > Is it really neccessary to add a "1" to well-known libraries, that have a > very small likelyhood of changing, and so do not present an issue to the > stated goals? ie: "libldns" -> "libldns1" :: is that really neccessary or > even useful? Everything will end some day, and so will libldns.so.1. When that happens, future maintainers will be grateful that we've made it easier for them to phase it out. While it's not strictly necessary to add the "1", I see no reason to object to that if a maintainer thinks it's a good idea. > What about when the software is actually known as "libFoo", and is at version > X, but the shared lib of the same name, is at version Y? This would lead to > grossness such as "libcups2-1.4.4". It is version2, but it is version 1.4.4? > This is confusing to a user, who at first glance (being used to our release > of things like "mysql4" vs "mysql5" packages, may think, "oh, there's a > version 2 of libcups" when there is not. Perhaps the foo.so.N+1 is an unfortunate case when the major software version is N. If you saw, say, libcups3, you wouldn't think it's the version 3 of cups as there's no version 2 of cups yet. While this could in fact be somewhat confusing to a user, I think it's very unlikely that it would. The libcups2 package is only a shared library, and will probably never be installed by itself. The typical two cases are installing cups itself, or installing cupsdevel to compile other software with cups support. As Sebastian has said before, it's unlikely any user would care about lib packages. To answer the main question about libFoo at version X with library at version Y -- the answer is that you follow the recommendation. Assuming you care about capitalization: CSWlibFoo contains everything minus devel, minus shared libs, etc, potentially unnecessary CSWlibFoo-devel with headers CSWlibfooY with the shared library (library package names are normalized with lowercase) > In these cases, perhaps it is better to encode the SONAME version information > somewhere other than immediately after the softwarename. Perhaps > libcups-1.4.4_so2,REV=2010.xx.xx? similarly, > libcupsimage-1.4.4_so2,REV=2010.xx.xx? libcupsimage-1.4.4,so=2,REV=2010.xx.xx > Hmm. except that would not allow for specific version-based dependencies. So > libcupsimage_so2-1.4.4, libcups_so2-1.4.4 ? We try to keep package names short, and the "_so" bit would be repetitive and not very helpful in most cases, but it's a possibility. WRT grouping libraries - yes, you are right that what matters here is whether libraries change together. Matching library versions is only a heuristic. We can emphasize this in the document if you want to. We can also replace this heuristic with something else, but we need a way to decide, given a set of sonames, whether they belong together or not. As Debian policy points out, it's always safe to split libraries to separate packages, and I think it's reasonable to nudge the maintainer about non-version-matching sonames in one package. I'm not pushing towards this being a policy; it can remain a best practices recommendation. I wouldn't mind it becoming the policy, but I understand that there is already a large number of packages, and not everybody will be happy to rework all their packages. What I would like to achieve is that if a maintainer submits a package following this recommendation, the package is not rejected on the grounds of doing so. What do you intend to do with your comments in on the wiki page? I guess we want to arrive at a clean version of the document that can eventually become our recommendation. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
