Re: Bug#987017: release-notes: Giving many ways to do something *is* useful
Paul Gevers <elbrus@debian.org> writes:
> Hi,
>
> [Release Team member hat on]
no hats here, but wanted to agree
> On 27-04-2024 11:48 p.m., Manny wrote:
>> As an aptitude user, I was bothered by the lack of aptitude ways of
>> doing things in the upgrade guide.
>
> I anything, I prefer the Release Notes to move to using one tool in
> the instructions, without insinuating that it's the only way. I think
> that tool should be apt nowadays. We've made steps in that direction
> during the last release cycle, i.e. we moved away from aptitude.
I agree. i myself use aptitude for upgrading to stable - it's a lot more
work than using apt, and I dont think it is suitable approach for new
users. (eg i am not sure that "aptitude safe-upgade" is actually
entirely equivalent to the first stage of apt, in some subtle ways).
I definitely dont want the release-notes to list every single possibile
way of doing things. It would make everything seem more complicated and
be very confusing - and need a lot of maintenance: i think that the
release-notes already try to do too much in some places.
Debian should be recomending a way to do things in a simple way that
will work. Advanced users can always do their own thing, but the
official release-notes should be simple -- it also helps people who want
to do their own thing if "the official thing" is clearly documented.
So I think release-notes should only use apt, with a brief note that
says that other front-ends like aptitude, synaptic are avialable. The
developers and users of those tools can write their own guide, if they
want, which could be linked to.
>> If the guide is intended to help train the user and advance their
>> Debian skills, then the CLI advice is probably favorable because it’s
>> more likely to improve the user’s knowledge than a UI that needs no
>> manual.
>
> That's not the purpose of the Release Notes.
(is there a case to think of something like this as a secondary
objective?, one to be kept in mind where possible, and only where it
doesnt conflict with a clear, short document. either way, documenting
objectives would help contributors)
>> As an aptitude user, my temptation is to look for the aptitude
>> approach. So merely omitting aptitude from the guide only encumbers
>> aptitude users. If there is a good reason for omitting an aptitude
>> approach, the guide should state why. Otherwise users might question
>> the quality and comprehensiveness of the guide.
>
> We could add a statement that while more tools exist. All automated
> testing of upgrades that I know of use apt-get, so that's the obvious
> choice. aptitude doesn't get as much testing.
i fear aptitude is mostly bugfix-only, whereas apt is actively
maintained with new features.
I really like the text interface in aptitude as it makes it easier to
track manual/automatic status and helps when you have complex
requirements like "install diffoscope-minimal but only some all its ~1GB
of transitive recommends" - but when I just want "the default" (the vast
majority of the time!), it doesnt actually add much over apt.
Reply to: