[csw-pkgsubmissions] newpkgs libnet, libnet1, libnet_devel

[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