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
Bug#484333: assigning to tech ctte (Re: status of this bug)
On Thu, Jun 05, 2008 at 09:25:24AM -0700, Don Armstrong wrote: the problem which you are describing is a general one that applies to all things which were dependencies which have been downgraded to recommends. You're describing the problem as if it had a property it doesn't have, which would make it general, and following that, asserting I'm describing a general problem, which I'm not. The problem with bash-completion is that it has *never* been a dependency of bash; it was split off without the intermediate state of being a dependency -- and I'm sure you'll agree that this intermediate state is existing practice (but if you don't, I can find examples). Once it has been a dependency of bash during the etch-lenny upgrade, I'm completely fine with it being downgraded to Recommends, or even Suggests. My concern is simply that no transition path has been contemplated. We've explained the transition path; it's upgrading while following the release notes. Given that no resolution has been issued yet, there's no explaining the. Use proposing a if you like, or anything that isn't misleading. Anyway, I don't agree that adding instructions about this in the Release Notes makes the problem disappear for everyone. In fact, I believe in this situation it's not very useful, because the kind of user who carefuly reads the Release Notes before an upgrade is also the kind of user who wouldn't have any trouble figuring out why TAB completion stopped working. As a result the burden of figuring out why hitting TAB misteriusly stopped working is put on the majority of users, The majority of users should be capable of reading the release notes. You're asserting something that is most likely true, but also irrelevant. It doesn't matter that Joe user is perfectly capable of reading the Release Notes if he doesn't actually read them. If you were to assert the majority of users carefuly read the Release Notes, would you have any evidence to sustain that? There's a reason why we spend the effort writing them. It is laudable that you spend effort writing the Release Notes, and I appreciate your effort. But this doesn't directly archieve the goal that all users follow all the instructions in them. A failure on the part of users to read documentation isn't an excuse for crippling a system, especially when the negative side effects of failing to read the documentation are minor. What you call crippling has been existing practice for ages. We're in the process of redefining that, and honestly I don't see what's the hurry about it. Are you seriously so concerned about those extra 216 kiB in the base install that you consider your system crippled because they can't be removed yet? If you look at the dictionary definition of crippled, you'll see that missing functionality is much closer to a match. Looks fine to me, but please clone instead of reassigning. If we decide that it should be handled in the release notes, that's where the bug goes. Who is we? I just checked the list in http://www.debian.org/intro/organization and you don't appear to be a member of the Tech Ctte. Did I understand wrong, and should the list be updated? This is not a bug in bash, but a problem stemming from apt not following policy. This is basicaly true, but then if you consider apt to be the real problem, it's a problem we can't solve untill lenny is released. Which brings us back to how do we solve the problem at hand: bash handling transitions as if apt were following policy, which it isn't yet. Here's a suggested resolution for a CTTE member to adopt and vote upon to resolve this issue: I suppose this answers my earlier question. Well, if you're not a member of the Tech Ctte, please don't speak as if you were. Seeing that suggested resolutions are possibly helpful, I thought I could do the same. Here's a suggested resolution for a Tech Ctte member to consider adoption (please excuse me for grammar/spelling mistakes, if any): -- Acknowledging that: (1) The lack of Recommends handling in apt has been a long-standing problem within Debian, and that it has been existing practice to use Depends to handle transitions when splitting a package, before the package relationship could be lowered to a Recommends. (2) Although the problem is solved in the lenny version of apt, the etch version is still affected. (3) The Release Notes maintainers may (at their discretion) adopt verbiage recommending that aptitude be used (or apt be upgraded) when upgrading from etch to lenny. (4) Although reading and carefuly following all the instructions in the Release Notes is the recommended practice, it is likely that a significant portion of users (and moreso, those affected by this problem) will only make a partial overview, and therefore is not safe to assume every user will follow all instructions. (5) The functionality currently provided by the bash-completion package is present in the default
Bug#484333: assigning to tech ctte (Re: status of this bug)
On Fri, 06 Jun 2008, Robert Millan wrote: On Thu, Jun 05, 2008 at 09:25:24AM -0700, Don Armstrong wrote: the problem which you are describing is a general one that applies to all things which were dependencies which have been downgraded to recommends. The problem with bash-completion is that it has *never* been a dependency of bash; The presence of a portion of the functionality within the package creates a de facto dependency; thus, it's a general issue. [..] Who is we? I mean we as in Debian, not we as in the tech ctte. In any event, I believe I have made my position on this issue abundantly clear, as have you. It remains to the tech ctte to jump in, adopt resolutions and/or decide one way or the other. Don Armstrong -- If you find it impossible to believe that the universe didn't have a creator, why don't you find it impossible that your creator didn't have one either? -- Anonymous Coward http://slashdot.org/comments.pl?sid=167556cid=13970629 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484333: assigning to tech ctte (Re: status of this bug)
[ Please don't drop me from CC. The BTS doesn't automaticaly forward mail to submitter. ] On Tue, Jun 03, 2008 at 01:07:29PM -0700, Don Armstrong wrote: On Tue, 03 Jun 2008, Robert Millan wrote: 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. It's not acceptable that end users get this functionality silently disabled without any obvious explanation (they might not even know which package provides it, or how). 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. Notice that according to popcon less than 24% of users run aptitude (18699 / 78518). I don't see how suggesting use of aptitude in the release notes will bring that close to 100%; in fact I doubt it would have any significant impact (but it doesn't hurt to do it anyway, IMHO). Besides, we're assuming that aptitude is a suitable replacement for apt in all situations, which may not necessarily be so. If you're really confident that it is, to be consistent you should IMO propose that apt becomes a dummy dependency on aptitude instead. 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. That would be if the dependency were to last indefinitely. The ability to not have bash-completion installed was (AFAICT) the whole point of the package split. My concern is simply that no transition path has been contemplated. As a result the burden of figuring out why hitting TAB misteriusly stopped working is put on the majority of users, just so that a minority doesn't have to wait untill the transition is complete to free 216 kiB from their disk. 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. Looks fine to me, but please clone instead of reassigning. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What good is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484333: assigning to tech ctte (Re: status of this bug)
On Thu, 05 Jun 2008, Robert Millan wrote: [ Please don't drop me from CC. The BTS doesn't automaticaly forward mail to submitter. ] Subscribe to the bug if you want to be sure to get all messages to it. 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. My concern is simply that no transition path has been contemplated. We've explained the transition path; it's upgrading while following the release notes. As a result the burden of figuring out why hitting TAB misteriusly stopped working is put on the majority of users, The majority of users should be capable of reading the release notes. There's a reason why we spend the effort writing them. A failure on the part of users to read documentation isn't an excuse for crippling a system, especially when the negative side effects of failing to read the documentation are minor. Looks fine to me, but please clone instead of reassigning. If we decide that it should be handled in the release notes, that's where the bug goes. This is not a bug in bash, but a problem stemming from apt not following policy. We can circumvent it as we've done often in the past, by suggesting that people use aptitude or upgrade apt before upgrading the rest of the system. Here's a suggested resolution for a CTTE member to adopt and vote upon to resolve this issue: -- (1) The release notes are suggested to adopt verbiage which explains that aptitude should be used (or apt upgrade) to properly handle packages where portions of the functionality were provided by a dependency are now provided by a recommendation. (2) Transitions between Depends: and Recommends: where the maintainer has correctly degreded a dependency are to be handled by release notes in the case where apt did not previously follow policy. -- Don Armstrong -- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: assigning to tech ctte (Re: status of this bug)
Processing commands for [EMAIL PROTECTED]: clone 468858 -1 Bug#468858: upgrades not properly handled (re: bash-completion) Bug 468858 cloned as bug 484333. reassign -1 tech-ctte Bug#484333: upgrades not properly handled (re: bash-completion) Bug reassigned from package `bash' to `tech-ctte'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484333: assigning to tech ctte (Re: status of this bug)
On Tue, 03 Jun 2008, Robert Millan wrote: 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. It's not acceptable that end users get this functionality silently disabled without any obvious explanation (they might not even know which package provides it, or how). 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. 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. 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. Don Armstrong -- The attackers hadn't simply robbed the bank. They had carried off everything portable, including the security cameras, the carpets, the chairs, and the light and plumbing fixtures. The conspirators had deliberately punished the bank, for reasons best known to themselves, or to their unknown controllers. They had superglued doors and shattered windows, severed power and communications cables, poured stinking toxins into the wallspaces, and concreted all of the sinks and drains. In eight minutes, sixty people had ruined the building so thouroughly that it had to be condemed and later demolished. -- Bruce Sterling, _Distraction_ p4 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: assigning to tech ctte (Re: status of this bug)
Hi, 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. 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. manoj -- Sattinger's Law: It works better if you plug it in. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
