[Debian GNUstep maintainers] Re: gratuitous -dev package renaming

[Steve Langasek]

On Sun, Feb 12, 2006 at 10:45:42PM -0700, Hubert Chan wrote:
> On Sun, 12 Feb 2006 00:56:22 -0800, Steve Langasek <vorlon at debian.org> said:

> > Are there really differences in the new version that warrant forcing
> > sourceful changes in all of the reverse-dependencies?  If not, I'm
> > inclined to NMU gnustep-base and gnustep-gui to Provide: the old names
> > of these -dev packages and schedule binNMUs for the affected packages,
> > so that this gnustep transition doesn't continue to drag on.

> Err.  Sorry, I should have caught this at first.  For most (for some
> value of "most") packages, a binNMU is not enough.  Due to the changed
> file locations, most packages would need their debian/rules modified to
> add "gsdh_gnustep" in the binary-* targets.  Otherwise, they may not be
> installable (if they have any files in the relocated directories).

Ok, then I'll definitely avoid meddling with those packages, thanks. 
(Though addresses-for-gnustep already got meddled with, and was probably one
of those affected, hmm...)

> AFAICT, though, most applications should be alright (though they should
> probably add gsdh_gnustep anyways, in case they later include files in
> the relocated directories).

Alrighty.

On Sun, Feb 12, 2006 at 10:12:16PM -0700, Hubert Chan wrote:
> On Sun, 12 Feb 2006 00:56:22 -0800, Steve Langasek <vorlon at debian.org> said:

> > Are there really differences in the new version that warrant forcing
> > sourceful changes in all of the reverse-dependencies?

> I think that the new versions of the libraries are backwards compatible
> with the old versions (i.e. all applications should build fine with the
> new libraries).

> > If not, I'm inclined to NMU gnustep-base and gnustep-gui to Provide:
> > the old names of these -dev packages and schedule binNMUs for the
> > affected packages,

> However, due to the directory structure changes for FHS compliance, none
> of the new -dev packages can be installed at the same time as any of the
> old -dev packages.  For example, if someone has libgnustep-gui0.9-dev
> (old) installed, which depends on libgnustep-base1.10-dev (old), and
> this pulls in libgnustep-base1.11-dev (new) because it provides
> libgnustep-base1.10-dev, then bad things will happen.

> But I would gladly welcome suggestions on how to fix this if you have
> any ideas.

Well, the solution that comes immediately to mind is for the new -dev
packages to conflict with those incompatible, old versions of -dev packages
which depended on them; e.g., libgnustep-base1.11-dev Conflicts:
libgnustep-gui0.9-dev (<< 0.10.2-1).  Normally, versioned less-than
conflicts are discouraged because they complicate upgrades, but for -dev
packages I don't think that's a problem.

> I also have a list somewhere of packages that should be removed, since
> they are not being used and we have lost their maintainer.  I hope to be
> able to send that to -release (? or where is the proper place to send
> it?) soon.

Packages that should be removed completely should be reported as bugs
against the ftp.debian.org pseudopackage.

> Thank you, Steve, for that much-needed kick in the pants.

Thanks for replying and letting me know where things stand.  I look forward
to seeing these various RC bugs closed in uploads in the coming days. :)

-- 
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 at debian.org                                   http://www.debian.org/