[csw-pkgsubmissions] newpkgs drill, libldns1, libldnsdevel, libunb(...)

[Philip Brown]

Getting back to this... sigh..



On 11/16/10, Ihsan Dogan <ihsan at opencsw.org> wrote:
> Hello Phil,

*wave*


> On 11/16/10 12:31 AM, Philip Brown wrote:
>
>> I'm not sure this is a good idea. why are you choosing to rename?
>
> Because of http://wiki.opencsw.org/packaging-shared-libraries .
>
>> It's worth noticing that the software's own name, is "ldns".
>> As noted by the URL that you still preserve in the pkginfo itself:
>>
>> http://www.nlnetlabs.nl/projects/ldns/
>>
>> so calling the package "libldns" seems to be against the author's
>> wishes to some degree.
>
> It doesn't say that I can't name the package libldns1.

It doesnt say that you "cant" name it
"wubbawubba-foo-fruity-ldns-is-cool" either.
That's not the point here :-}



>> and then there is the needless making it "libldns1" instead of just
>> plain "libldns".
>> What is up with this stuff?
>
> I've spent quite some time with packaging and testing unbound and
> libldns1 properly and I really don't see what's wrong with these packages.


Ihsan, I have every confidence in you, that you made properly
functional packages :)
Naming is important too, though.

There are two additional factors here that are under consideration:

1. The package was previously released, and for quite a long time,
under the name "ldns".
If it were a brand new package, I would be a bit less picky about this

2. I went to compare other distribution naming.  If it was a standard
to call the related stuff "libldns", I would have said "okay".
Unfortunately, it is split:  debian does indeed call it "libldns".
However, redhat calls it "ldns".

(along with "ldns-python")

debian appears to be inconsistent about its naming.
On the one hand, it has "libldns", but then it has "ldnsutils"
AND, "python-ldns".

This indicates to me that debian "loses" influence, because of inconsistency.

I acknowlege that it would be an irritation to repackage, given that
you would have to redo multiple ones, due to dependancy use :(

In light of the additional information I've mentioned above, though;
would you consider repackaging please?

before you do, though.. now that I've had to do some more digging:-/
there's also the question of why "drill" is a uniquely named package
by itself.
To compare;  debian includes it as one of multiple programs, in "ldnsutils".
redhat just includes it in the core "ldns" package, along with those same utils.
 (the utils are built by doing a make in the 'examples' dir)

Doi you want to bring us up to the level of the other distros, and
include those in some package?

One possible path you might consider, is:
 -  put the "drill" binary, along with the other utils like
ldns-read-zone, in a "ldns" package.
 - repackage an "empty" 'drill' package, that just depends on ldns
 - 'ldns' depends on libldns1
 - leave rest of packages as-is

How does that sound?