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@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@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@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature