On Fri, Jul 16, 2010 at 11:59:45AM +0200, Frans Pop wrote:
> Steve Langasek wrote:
> > This manual represents the opinion of a single developer.
> And what does that have to do with the price of bananas in Iceland?
> The fact that aptitude is currently the recommended tool for package
> management has various reasons: user interface, features, dependency
> handling, etc. That status has evolved over the last 3 or so release
> cycles. You have even been part of some of the discussions (for example
> sarge -> etch upgrade issues)
"Dependency handing" is certainly not a reason to recommend aptitude.
Yes, I was part of the discussions recommending it for release upgrades in
the sarge and etch timeframe. For lenny, I strongly counseled *against*
recommending aptitude for release upgrades, due to some concrete regressions
in aptitude's upgrade handling at the same time that apt itself had reached
parity on all the relevant features (improved upgrade resolver; Recommends
handling). It remained in the release notes anyway owing to concerns that
it was too late in the cycle to get good tester feedback on upgrades using
apt-get, but I intend to again advise removing aptitude from the squeeze
release notes in favor of apt-get. aptitude's resolver is just too
inconsistent and has too many pathological edge cases for it to be a good
idea to recommend its use as a dist-upgrader.
Now for interactive upgrades, aptitude does have the best interface. But it
doesn't follow that it should be Priority: important as a result; there are
any number of packages that we may recommend for one purpose or another that
nevertheless shouldn't be installed as 'important'.
> aptitude is the primary tool used by Debian Installer (and because of that
> its current priority of "important" is actally necessary).
This is the only reason I see that it should be 'important'. I'm not (yet)
convinced that this is necessary. Some alternatives would seem to be:
- opportunistically install aptitude when a user wants fine-grained
package selection in the installer; otherwise only install it when the
'standard' task is selected. (Downside: user has to wait for aptitude
to be installed, introducing delay at another point in the installer.)
- have the installer special-case the automatic installation of aptitude in
spite of not being Priority: important, so that it's available at the
right point in the installer. (Downside: special-casing; and if the user
doesn't select the standard task, we either uninstall it at the end of
the install leaving users without access to this interface post-install,
or we leave it on everybody's system anyway, in which case it might as
well just be Priority: important.)
These are some other options to think about, but on balance, I would
conclude that raising the priority of libboost-iostreams to important is
actually the right solution. Boost is an annoyingly unstable library to
depend on and its library transitions are painful, but most of the
individual component libraries (including libboost-iostreams) are actually
quite small with no unusual dependencies; and raising one of these
components to important shouldn't cause any problems.
> It is also recommended in both the Release Notes (for stable release
> upgrades) and the Installation Guide.
The first of these is a bug that needs fixed. The second is a reasonable
recommendation if we're pointing users at the TUI; for the CLI we should
simply recommend apt-get.
> So what's listed in the "Debian Reference" is a correct reflection of
> aptitude's current status and not, as you imply, the result of some single
> developer being on crack.
Right, it's the result of several developers being on crack. :-P
Regardless of whether there are other developers who agree with this
particular opinion (which, for any given opinion, is bound to be the case),
I think it's important to distinguish between documents whose drafting is
done on open mailing lists and whose recommendations are the result of
consensus (Debian Policy; DevRef, now that it's on debian-policy;
Installation Guide; Release Notes) and those that are maintained by
individuals. The latter are useful, but are not the word of the Project.
--
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/
slanga...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
