[csw-maintainers] Naming and layout of libnet packages

[Dagobert Michelsen]

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 <dam at opencsw.org> 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
> pkgsubmissions at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/pkgsubmissions