[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: transition plan from libcap to libcap2



* Torsten Werner [Mon, 23 Feb 2009 22:18:48 +0100]:

> Hi,

Hello, Torsten, and sorry for the awfully late reply. Since this wasn’t
an imminent transition, I’m afraid it starved a bit.

> libcap is no longer maintained upstream and has been replaced by
> libcap2 which is supposed to be API compatible. There are some
> packages left that Build-Depend on libcap:
> <http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libcap2;users=twerner@debian.org>.
> My plan is to add a transitional binary package libcap-dev to the
> source package libcap2 until squeeze will be released and remove the
> source package libcap from unstable. After some binNMUs everything
> will be okay. The maintainer of libcap (Michael Vogt) agrees to the
> plan.

> Are there any problems with the proposed transition plan from the
> release managers point of view?

If libcap is no longer maintained, then yes, work should be put on
moving away from it. Thanks for pushing this.

The plan you outline should work, yes. I would have one suggestion,
though. How about making the libcap2 source package just provide
“libcap-dev”? It is preferred that development package names don’t
encode the SONAME version in their names, and if I’m inferring
correctly, libcap2 is the current and preferred version of libcap, so it
makes sense in my eyes that it stays that way.

I would recommend in that case that the libcap2-dev package gets
completely dropped (and not even kept as eg. a transitional package),
provided that you make the new libcap-dev Provide: libcap2-dev, in order
not to cause unnecessary FTBFSes.

I’ve checked the archive, and only two packages (avahi and ltp) have a
versioned buid-dependency on libcap2-dev. It’d just be a matter of
filing those two bugs after uploading libcap-dev 2.16-3 to unstable.

Thoughts? At any rate, whenever a libcap-dev 2.16-3 or higher hits
unstable, please let us know and we’ll schedule the required Bin-NMUs.
Would you be up to the task of tracking their results, and file bugs as
appropriate (with some usertag, etc.)? Feel free to say no if you really
can’t.

Thanks,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
Truth is the most valuable thing we have, so let's economize it.
                -- Mark Twain


Reply to: