• Re: Bug#987017: release-notes: Giving many ways to do something *is* us

    From Richard Lewis@21:1/5 to Paul Gevers on Sun Apr 28 12:20:01 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)