Bug#484333: assigning to tech ctte (Re: status of this bug)
[Cc:ing the bash maintainer, who should definitely be a party to this
discussion.]
On Sat, May 31, 2008 at 01:25:25PM +0200, Robert Millan wrote:
> I think this shows clearly there's an unresolved transition here.
> I understand bash-completion shouldn't be Essential, but the
> process for moving it out isn't being done properly.
Just as a point of information, being a dependency of bash would not include
bash-completion in the Essential closure. Only making it a pre-dependency
of bash would do this, and nobody is arguing for this.
Ok, it would be a little odd to keep your system in a state where bash was
perpetually unpacked but never configured (due to unsatisfied deps), but it
could be done. ;)
On Tue, Jun 03, 2008 at 01:07:29PM -0700, Don Armstrong wrote:
> The release notes can trivially deal with this by suggesting (as they
> currently do!) that users use aptitude, which even in etch, handles
> Recommends: properly. They can also mention this specific problem, and
> handle the general class of problems where packages have been demoted
> to Recommends and/or split.
The change from recommending apt-get to recommending aptitude in the release
notes was originally made because aptitude's Recommends support, and better
resolution of a particular set of common upgrade cases, made for a
consistently better upgrade experience.
However, I'm no longer convinced this is the case; in etch and later,
aptitude's resolver seems to have become less and less able to cope with
suboptimal upgrades. I wouldn't assume that aptitude will remain the
recommended upgrade tool for lenny without confirmation from the release
team.
Also, I seem to remember a difference between aptitude's handling of
Recommends of newly-installed packages, vs. Recommends of packages that are
being upgraded.
I agree that it would be reasonable to discuss package splits in the release
notes (I think we used to keep a list of split and superseded packages in
the release notes), but no one has in recent releases volunteered to take
responsibility for maintenance of such a list.
> Making bash-completion a dependency of bash obviates one of the
> important advantages of splitting out bash-completion: the ability to
> not have bash-completion installed.
The first advantage of splitting out bash-completion is that doing so
eliminated a significant delta between the Debian bash package and upstream
- bash-completion is not distributed as part of bash upstream, so this
constituted a massive diff.
The second advantage is that Matthias no longer had to take responsibility
for bash-completion, since as a separate source package it could have a
separate maintainer. :)
I had a couple of conversations with Matthias about this package split in
the context of Ubuntu packaging, and "keeping it from being installed" was
never mentioned as a primary motivation. Indeed, once the package was split
there was discussion within Ubuntu about whether it should be a Depends or a
Recommends going forward, with upgrades never being a major point of
discussion that I can recall.
> I suggest reassigning this bug to release notes with the following
> suggested verbiage:
> If you use apt-get to upgrade to lenny, you should first upgrade apt
> to the version in lenny, and then complete the upgrade to lenny
> using that version. The version of apt in lenny properly handles
> packages which have been split, with significant features only
> Recommended: by the unsplit packages.
I don't think this is at all a satisfactory resolution of this issue. For
both sarge and etch, trying to upgrade the package manager to the new
release ahead of the rest of the system was not an effective strategy,
because of the dependencies that had to be satisfied in the process. For
etch, the "minimal" upgrade path described at
<http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#s-upgradingpackages>
was about three times as complex as I would have liked it; trying to upgrade
the package manager first would have made it even more complex.
So if we ask that the release notes recommend upgrading apt to lenny before
doing the full dist-upgrade, we are significantly constraining the release
team's options for handling other upgrade problems that arise later when
full-scale upgrade testing commences.
For precisely this reason, I believe the correct resolution of this bug is
that bash should depend on bash-completion on a transitional basis. This is
the only satisfactory *local* solution to the problem; any other solution
either has broad-reaching effects on the upgrade process as a whole and
therefore isn't robust in the face of the sort of conflicting upgrade
requirements that tend to be identified late in the release cycle, or relies
on users to take explicit action (i.e., read the release notes).
Perhaps I'm in a minority, but I think documenting issues in the release
notes constitutes an imperfection. Not quite a bug or a failure, since
there are definitely cases where design decisions have been made outside of
our control that we would never spend the time trying to automate around,
but all the same, any time we have to document an upgrade issue in the
release notes instead of making the upgrade issue go away, that upgrade is
not as perfect as Debian upgrades have the potential to be. So I will
always prefer to address issues such as this in the package relationships
instead of punting to the release notes.
On Thu, Jun 05, 2008 at 09:25:24AM -0700, Don Armstrong wrote:
> > That would be if the dependency were to last indefinitely.
> It would last for the entire next release cycle, and moreover the
> problem which you are describing is a general one that applies to all
> things which were dependencies which have been downgraded to
> recommends.
I agree with Robert here; this is a question of packages being split, not of
downgrading Depends to Recommends. Downgrading package relationships from
Depends to Recommends between releases does /not/ cause this issue, because
packages that were previously depended on will already be installed on the
system and will be handled accordingly by the package manager (i.e., they'll
normally be upgraded rather than removed).
This is a problem specific to splitting of packages. And historically, yes,
I think we have tried to ensure when packages are split that the
pre-existing package depends on the new package, when appropriate and
possible, for the next release, so that upgrades work as users expect them
to.
On Tue, Jun 03, 2008 at 05:55:46PM -0500, Manoj Srivastava wrote:
> Isn't this kind of thing the normal fodder for the Release
> Notes? I seem to recall a number of upgrades where upgrading the
> package management tools _first_ was the only way to achieve a smooth
> upgrade, and this seems to be no different.
The sarge release notes recommended something of this sort. (They were not
the first to do so, but they're the first I can answer for with certainty
because of my direct involvement in that release.) The etch release notes
did not; it was discussed, but upgrading the package manager on its own
before the rest of the system was not practical because of the many
inter-release conflicts that were involved in going from sarge to etch.
This could have been addressed by backporting the etch package management
tools to sarge and making them available in a special upgrade repository,
but we had no way to cause use of that repository to be auto-configured for
users, so we would have still had the problem that:
- The only way users would find out about the upgrade repository is by
reading the release notes.
- Most users don't read the release notes, and expect apt-get/aptitude
dist-upgrade to Just Work.
- Implementing a solution that requires the users to read the release notes
won't teach a significant number of these users to read the release notes,
it will just give those users a worse upgrade experience.
- Knowing that many users are not going to read the release notes, it was
necessary to understand what would happen when using the sarge package
manager for upgrading, and document this anyway.
So given the limitations of that solution, no one spent the effort on
backporting the package management tools. I don't see why things would turn
out any differently for lenny.
FWIW, Ubuntu /has/ implemented a solution for this; Ubuntu has a
do-release-upgrade tool that is the single recommended inter-release upgrade
path, and deals with all of the "quirks" that can't be handled by apt-get
alone, pulling in software from a special upgrade archive to handle this.
(apt-get still generally works, of course, but the outcome is not guaranteed
to be supported.) I don't think it would be a bad idea for Debian to adopt
a similar, general solution (possibly by having the installer add a
sources.list entry pointing to an upgrade archive which is required to be
carried by all mirrors but only populated with particular packages at the
time of the next release?), but that falls well in the realm of "design
work" and should therefore be regarded as out of scope for this committee.
> If the decisions is between having the release notes specify that package
> management tools have to be upgraded first, and not allowing users the
> freedom to install on,ly bash, and not the auto-completion package, it is
> entirely reasonable that the release team picks the former.
When did this become a release team issue? I haven't seen that the release
team has taken any decision at all on this question.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: