On Wed, May 03, 2006 at 08:59:00AM +0200, Frank Küster wrote:
> Steve Langasek <vorlon@debian.org> wrote:
> > On Tue, May 02, 2006 at 02:23:04PM +0200, Frank Küster wrote:
> >> Dear release team,
> >> libkpathsea3 is obsolete, and we're hoping to be able to remove it from
> >> the archive for etch. A couple of packages still depend on it. Since
> >> the API hasn't changed, and libkpathsea4-dev now provides
> >> libkpathsea-dev, a rebuild of the package should be sufficient.
> > I'm afraid not. Because these packages build-depend on libkpathsea-dev (I
> > assume -- I haven't reviewed all of them), and there is still a *real*
> > libkpathsea-dev package in the archive, the autobuilders will prefer this
> > real package instead of libkpathsea4-dev's Provides.
> I tested in a sid pbuilder chroot:
> # apt-cache policy libkpathsea-dev
> libkpathsea-dev:
> Installed: (none)
> Candidate: 3.0-16
> Version table:
> 3.0-16 0
> 500 http://localhost sid/main Packages
> root@riesling:/# apt-get install libkpathsea-dev
> Reading package lists... Done
> Building dependency tree... Done
> The following extra packages will be installed:
> libkpathsea4
> The following NEW packages will be installed:
> libkpathsea-dev libkpathsea4
> 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
> Need to get 151kB of archives.
> After unpacking 590kB of additional disk space will be used.
> Do you want to continue [Y/n]?
> and concluded that the only problem would be that some buildds might
> have libkpathsea3's dev package already installed.
Oh, sorry; the fact that the libkpathsea3 source package still includes
libkpathsea-dev confused madison (and me) into thinking this was still the
old libkpathsea-dev. (This is an RC bug on libkpathsea3, btw, since that
package can no longer be uploaded in its present state...)
> > If you remove libkpathsea-dev from the libkpathsea3 package (or drop
> > libkpathsea3 altogether from unstable), then it should be possible to binNMU
> > these
> Dropping completely would be a task for the ftpmaster, correct?
Yes, upon request of the package maintainer.
> > -- assuming they're all binNMU-safe. (have you checked for that,
> > btw?)
> No, sorry, I didn't think about that - I'll will check it. What are the
> things to look for? The only problem I'm aware of is when a source
> package also builds arch-all packages and have =${Source-Version}
> dependencies (or does Source-Version now discriminate between normal and
> binNMUs?)
The main problem is the Source-Version dep between arch: any and arch: all
packages, yes. Source-Version will never discriminate between the two,
though dpkg will hopefully soon have some new options to supersede it.
Anyway, I've scheduled binNMUs for the source packages cjk-latex, dvi2dvi,
dvipng, evince, lcdf-typetools, texfam, tkdvi, and tmview, which are the
packages I found which still depend on libkpathsea3 in current unstable
versions of the packages.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature