[+maintainers, bcc:pkgsubmissions] Link back to the start of the thread on pkgsubmissions: http://lists.opencsw.org/pipermail/pkgsubmissions/2010-November/001528.html
No dia 9 de Novembro de 2010 16:47, Philip Brown <[email protected]> escreveu: > On 11/9/10, Maciej (Matchek) Blizinski <[email protected]> wrote: >> No dia 8 de Novembro de 2010 20:10, Philip Brown <[email protected]> >> escreveu: >>> >>> bug #2: erm... so how come something named "libcups **2**", has >>> version=1.4.4 ? >>> that's very confusing. >> >> It's the same naming scheme as with every other shared library. If >> you look at the soname, it's libcups.so.2, which gives us CSWlibcups2. >> It has been built from cups sources version 1.4.4, and hence the >> version. >> > > I dont think "the same as every other shared library" quite fits, > here. There are many libxxx packages that do not fit that naming > scheme. > I'm thinking this is the "new" library naming scheme you proposed, yes? Yes, that's it. > Do we have the specifics of the proposal up somewhere, either on main > site, or on wiki? There is a best practices writeup on the wiki, on the checkpkg error tags page, about the shared-lib-pkgname-mismatch tag. It links to the original discussion on the mailing list; the rationale is written up in the first post. There's also a link to a file with unit tests and examples of 12 different sonames and resulting package names. http://wiki.opencsw.org/checkpkg-error-tags#toc5 > Although your libpython seems relatively fine. > your libcups2 package does not match that. oh wait, it sort of does... > this is a single-digit-rev shared lib. > Which fits my original addendum to the proposal, if I recall: > "[libraries with single-digit (version numbers in the file) do not > usually need to be split out" > > This would seem to be the case for cups, where the SONAME has not > changed in over 3 years. I don't think your proposed addendum got accepted, did it? I have discussed this and explained why the number of elements in the soname version does not affect the shared library life cycle. Here's the reference: http://lists.opencsw.org/pipermail/maintainers/2010-October/012850.html > using our existing defacto standards of naming, having > > softname > and > softname2 > > usually means two separate, different-by-major-number versions of the > software. > So libcups2 is confusing. What do you mean by confusing - what else do you think it could be? Let's consider a hypothetical release of cups version 2, which could be installed together with cups 1.x (regardless of how much sense it could have). I think this is the scenario you had in mind. Cups version two would probably increment the soname version of libcups, or change the soname altogether. Distributed files would be libcups.so.3, or libcups2.so.1 (or similar). Here's a rundown of hypothetical sonames of cups2 and resulting package names: example 1: libcups.so.3 - CSWlibcups3 example 2: libcups2.so.1 - CSWlibcups2-1 example 3: libcups2.so.2 - CSWlibcups2-2 example 4: libcups2.so - CSWlibcups2 Only the example 4 could be ambiguous; but changing the soname from libcups.so.2 to libcups2.so would be an evil thing to do, and I don't think cups developers would ever change the soname that way. I doubt that it was the scenario you had in mind. Barring the hypothetical libcups2.so example, the CSWlibcups2 package name is unique and explicit. Here's an important note on package names: The package names (pkgname and catalogname) depend solely (!) on sonames. They explicitly do not depend on project names, or sources versions. CSWlibcups2 is named the way it is because it contains libcups.so.2. The "cups" word is there just by coincidence - it so happens that the project name is embedded in the soname. Does this explanation make it more clear to you? > softname2_x_y is a bit more indicative of the sharedlib scheme you've > proposed. > Perhaps the proposal needs something a bit more explicit to denote > "this is a split-off shared lib", since we've found a case where > having a leading "lib" is not sufficient to denote that any more. Do you mean some kind of naming prefix unambiguously identifying packages with shared libraries? What would be its purpose? The core of the package naming policy is that every soname has its own pkgname and catalogname. It's not about a perfect mapping from pkgnames to shared library names, or about identifying packages with shared libraries just by package names. The purpose of the soname-driven naming is to facilitate a healthy shared library life cycle. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
