Re: How are things going?
On Tue, Sep 26, 2006 at 09:13:23PM +0200, Nicolas François wrote:
> > I'm rather worried that there's been no apparent progress on getting
> > Ian's Breaks support merged in, especially since in my limited
> > understanding it's already present in Ubuntu and presumably being used
> > there. That doesn't seem very good for cross-distro package
> > compatability if our dpkg ignores the field.
> The first patches were applied in the dpkg's repository.
> This means that the svn version should support packages using Breaks (I
> mean not reject them, but they will not use the content of these fields).
> IIRC, the same remains to be done for dselect.
> Before going farther, the next step must be pushing 1.13.22 to testing.
> It was locked in unstable because of the perl RC bug, which caused dpkg to
> FTBFS.
> This version of dpkg is now in unstable since more than 3 months and
> should have receive enough tests. I'm CCing debian-release to see if this
> version can be pushed to testing.
Yes, since this version has been in unstable for three months already
without major incident, it doesn't make sense to keep it out of the release,
especially since it's the version that will be used for building so many of
our binary packages included in etch.
So I've unblocked it after reviewing the changelog.
On Wed, Sep 27, 2006 at 01:09:26PM +0300, Guillem Jover wrote:
> > Regarding the next dpkg version, the patch is quite large, but it's mostly
> > l10n stuff. Would the current 1.13.23 be acceptable to bypass the dpkg
> > freeze? [1]
> I've created a diff[2] with the new commited stuff and removed all
> autogenerated things (I've not removed the comment changes for
> completeness). Debian chanelog and upstream ChangeLog are in the
> header of the patch.
> Basically the changes are:
> * The tar 'nul' warning fix.
> * The Breaks field.
> * Using dpkg-architecture from the source instead of duping its
> logic in the m4 files (this is kind of a requisite for the armel
> architecture introduction).
> * Comments or new line fixes.
Since "Breaks field" here means "doesn't complain about the Breaks field",
rather than "honors the Breaks field", these changes look ok.
As far as *implementing* Breaks, I don't think a new feature of that level
should be introduced during a freeze.
BTW, with the changes to scripts/dpkg-architecture.pl, does something fix
the dpkglibdir and pkgdatadir paths when installing this script?
Thanks,
--
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/
Reply to: