Re: dpkg-buildpackage now reorganizing debian/control Depends field??
On Sun, 24 Feb 2008, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: dpkg-buildpackage now reorganizing debian/control Depends field??"):
> > I won't revert anything unless you come up with some proof that this
> > causes severe issues that will disturb the lenny release process.
> I think this is the wrong approach.
> Surely you should revert the change if people can demonstrate that
> it's wrong ?
However, in the message that you quoted:
1/ nobody had yet wondered why I made the change and nobody had made any
proposal to solve my issues at the same time
2/ Otavio was sort of acknowledging it as a good thing but a good thing
that should be delayed for an unknown amount of time waiting for a fix on
apt's side while the lack of fix didn't seem to create important problems
Under those conditions, I tend to react negatively. :)
Given the other (more constructive) exchanges (thanks to Mike Bird, Steve
Langasek, Daniel Burrows and Josselin Mouette), I'm willing to revert the
change but if we really want to keep 100% determinism, it's not going to
be trivial since the dependency simplification code probably needs to be
a bit reworked.
I'll do by myself:
- remove the global sort
- sort the output of dpkg-shlibdeps
I'd be glad if someone else could help with:
- file wishlist bug on any other program creating substitution variables
containing dependencies (on top of my mind at least: python-central,
- review the simplification code and make it replace the removed
dependency by the superseding one if the replaced one appears
before the superseding one, otherwise just delete the remove dep
and keep the superseding one at his current place
- documenting everything (in dpkg-gencontrol(1)/dpkg-source(1))
- that the order within dependencies field is meaningful and will be kept
- explain how the simplification of deps is done
(That said I'll put it on my TODO list so I might eventually end up doing
Le best-seller français mis à jour pour Debian Etch :