Hi, (reposting to maintainers@ for general package naming discussion)
Best regards -- Dago Am 19.11.2010 um 10:54 schrieb Dagobert Michelsen: > Hi Phil, > > Am 18.11.2010 um 22:51 schrieb Philip Brown: >> On 11/18/10, Dagobert Michelsen <[email protected]> wrote: >>> Am 17.11.2010 um 18:57 schrieb Philip Brown: >>>> Two comments: >>>> >>>> 1. the SONAME is libnet.so.1 >>> >>> Partly correct. The SONAME of libnet.so.1.0.2 is libnet.so which is >>> the one all existing packages link to: >>> http://www.opencsw.org/packages/libnet >> >> For other peoples' benefit, here is full information: >> >> 1. OLD "libnet" package contained a libnet.so* file, which other >> programs required >> as only "libnet.so" >> >> 2. The "real filename" of the old package was libnet.so.1.0.2. >> However, that is kinda irrelevant since nothing referenced it directly >> as such >> >> 3. NEW "libnet", contains a symlink "libnet.so.1.0.2". > > Umh, no. /opt/csw/lib/libnet.so.1.0.2 is a file as always and libnet.so > is a symlink pointing to it as always. > >> This is, as I >> mentioned, completely irrelevent, since no "old" stuff uses it,and >> "new" stuff has libnet.so.1.6.0 > > I think it is good to have libnet.so pointing to libnet.so.1.0.2 to > make it explicit what version libnet.so is pointing to instead of > having just a file libnet.so with the contents of libnet.so.1.0.2 > in it. > >> 4. NEW "libnet" has an actual SONAME of "libnet.so.1" > > Right. > >>>> Why do you then provide a symlink >>>> /opt/csw/lib/libnet.so=libnet.so.1.0.2 >>>> It would seem to be completely unneccessary. >>> >>> Just for clarity. I could put the libnet.so.1.0.2 directly in >>> libnet.so without loss of functionality, but personally I prefer to >>> make the version explicit as there is no other place where you >>> can see the library version. >> >> clarity of what? I Dont Get It. >> And speaking of "I Dont Get It"... I also dont get what provides the >> backwards capability for older stuff needing libnet.so. >> >> oh wait, I didnt notice that you provide the actual binary compat lib >> in "libnet", in addition to the symlink. > > Yes. > >> Justaminute... Even though I'm suggesting not following the proposed >> standards.. doesnt your implementation, break the proposed standards >> too? :) > > Probably, because it is a legacy library and does not have a SONAME anyway. > >> Seems like CSWlibnet, should depend on a new "CSWlibnet0" for now: >> Then that, and only that, should have the older compat >> libnet.so.1.0.2, and libnet.so symlink to it. > > ...which would break the standards too as .so should be in _devel. > But again, libnet is not a standard library. It is a legacy piece > of crap where the library broke even existing SONAME standards. > >>>> 2. Given that this is a "lib" package... having "lib_devel" would seem >>>> to be redundant. >>>> What do you think of my addendum to the wiki proposal, where for >>>> 'lib*' packages specifically, we just put the "devel" stuff in the >>>> straight "lib" package? >>> >>> I don't like it because the devel part of some libraries are excessively >>> large where you would like to keep the devel package. >> >> I may be missing something here. >> >> What I'm seeing, is that if we stuck to the proposal,it would mean: >> >> applications that need the lib, would depend on CSWlibfoo#-#-#. >> They would not pull in CSWlibfoo-devel, or anything else. To compile >> stuff, people have to add in CSWlibfoo-devel > > Correct. > >> What I an suggesting is almost identical: >> applications that need the lib, would depend on CSWlibfoo#-#-#. >> They would not pull in CSWlibfoo, or anything else. To compile stuff, >> people have to add in CSWlibfoo > > This would be good if all libraries would play well. A ton of packages > depends on CSWlibnet, so that one must contain the old libnet.so. If you > want to add the devel stuff to CSWlibnet that is doable, but it would be > the devel-files **from the new** libnet library. Personally I would find > this very confusing. > >> To me, this makes contextual sense, because if a user explicitly wants >> to use "libfoo" directly, they can say "I want libfoo installed", aka >> "pkg-get install libfoo", and be ready to go. The "_devel" part is >> redundant to a library package, if you've already split out the actual >> shared library itself to a different package. >> >> I dont see how a user ever ends up with 'devel' type stuff that they >> dont need, in either case shown above. > > As I said: existing packages depend on CSWlibnet which would then > contain devel-stuff from another version. Additionally, having > a clean _devel-policy like "if you want to compile x you must install > x_devel" is very simple and could be even be made an automated > check, but only if done consistently. > >>> One more argument for having a separate devel: When we split out >>> real libraries like CSWlibnet1 containing libnet.so.1.1.5 the >>> merging of devel in there makes some of the advantages useless. >>> When some libnet.so.2.x comes out CSWlibnet1 would need to be respun >>> to rip out the devel stuff as this would now be shipped in CSWlibnet2. >> >> well yes. IF (andonly if) we thought it advantageous to be able to >> develop on both versions of the library, we would want to maintain >> "libnet1", and "libnet2" > > We don't want this. And I don't see how this related to my statement. > Putting devel together with a library will lead to repackaging > of the library package if another SONAME comes out as the devel > part needs to be relocated to the new package, so both need to > be rebuilt. *Not* to rebuild all packages is one of the goals > of the library suffixing with the so-number. > >> However, in most sane cases, we only care about development with "the >> latest" version of something. So do most people. >> Again, if they want to pull in "libfoo" to compile with, they probably >> are just using some kind of general requirement, and dont really want >> to think about "well, I need to get 'libfoo-vx-y. IF it's available. >> oh wait, opencsw doesnt have that yet. Hmm.. I wonder what version >> they have.. .checking... okay I'll specifically select libfoo-x-y to >> install now'". >> >> Kinda annoying. I'm thinking most users are just ripping through >> compile requirements, and they just want to "get the latest". >> So having "CSWlibfoo" track to "development for 'the latest' libfoo", >> I see as a feature for the users, rather than a negative overall. > > I don't see how this is more difficult than to say "If I want to > develop with libfoo I need to install CSWlibfoo-devel". > >> So to be more explicit, I'm suggesting that, *specifically for library >> packages only", >> "libfoo" contains >> - a dependancy on the latest shared library version we support >> - the dev files to compile against it. >> >> Does that sound more appealing? > > In general this sounds not too bad, but > - it is really bad for legacy libraries like libnet > - it is not consistent to have _devel for some packages but not for others. > > Having a consistent _devel would allow something like "List all CSW > packages and install <pkg>-devel" and everything will work. > > > Best regards > > -- Dago > > _______________________________________________ > pkgsubmissions mailing list > [email protected] > https://lists.opencsw.org/mailman/listinfo/pkgsubmissions _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
