[csw-pkgsubmissions] newpkgs libnet, libnet1, libnet_devel

[Philip Brown]

On 11/18/10, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Phil,
>
> 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". This is, as I
mentioned, completely irrelevent, since no "old" stuff uses it,and
"new" stuff has libnet.so.1.6.0

4. NEW "libnet" has an actual SONAME of "libnet.so.1"


>> 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.
Justaminute... Even though I'm suggesting not following the proposed
standards.. doesnt your implementation, break the proposed standards
too? :)
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.


>> 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

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


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






> 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"

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.

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?

*(bat)*