Paul Gevers <elb...@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.
