On Mon, 25 Jan 2016 19:11:40 -0500 Francis Gerund <ranr...@gmail.com> wrote:
> So again, perhaps some automated mechanism for upgrading might be > beneficial. Or at least some elaboration or amplification of the > documentation on this subject. And how about a simple guide to "this > is how you update to testing"? I disagree entirely. Improved documentation? Sure. We could always do with some more of that. But I really don't think automating the update procedure is the best way to go about handling stable > testing updates. You seem to think there should be some BRB in Debian's GUIs labelled 'upgrade to Testing here!' to make things 'easy'. If not, a command-line script would be redundant, because anyone who is prepared to do the research on how to use the script should be familiar with Debian's archive system and capable of writing their own /etc/apt/sources.list. Sometimes it is necessary to strike a compromise between user-friendliness and control. Casual users who aren't prepared to trouble-shoot and just expect everything to work *should not* be using testing or unstable, simple as that. Whenever I want to use testing on a new install from stable, I just throw up a new /etc/apt/sources.list looking something like this: deb http://http.debian.net/debian testing main deb http://http.debian.net/debian testing-updates main deb http://security.debian.org testing/updates main and I'm good to go. It takes a few minutes at the most. Anyone trying to run Testing should be a) familiar with the Debian archive system and what each of the archives contain, b) able to edit a config file. The current system isn't 'user-unfriendly' it just allows more control than you would like it to. I really don't see how having an upgrade script could possibly simplify things and still allow control over the archives used without effectively making itself redundant by asking exactly the same questions that one would have to know the answer to when upgrading the proper way. If you want to run testing, you should be able to write your own sources.list. It is a basic skill. If you want to find out how to track the current testing permanently, have a look at an actual mirror and see what's available! From a quick scan of http://ftp.acc.umu.se/debian/dists/ I can see that aliases for stretch exist, and can thus conclude that I can permanently track the current testing when it becomes stable by using a 'stretch' entry in my sources, without ever having had to bother the mailing list with a question you could have easily found the answer to yourself. > (BTW, Google is NOT "your friend". Says the Gmail user. > And the more I think about it, the more I stand behind my opinion that > upgrading is unnecessarily difficult and error-prone. > > Whew! Now that that's out of the way, let me ask: > > When (and why would you use full-upgrade, as opposed to dist-upgrade > (and how does aptitude figure into that)? I don't use aptitude, I'm > used to apt-get. This is something of an oversimplification, but full-upgrade is aptitude's equivalent to apt-get's dist-upgrade. As for use, either should be used on a regular basis- the former if you are an aptitude user, and the latter if you are an apt-get user. It is a bad idea to use both. Either aptitude full-upgrade or apt-get dist-upgrade should be part of your maintenance routine. Either should be used on a regular basis. > Thanks for your reply. <snip> Please stop top-posting. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? https://en.wikipedia.org/wiki/Posting_style#Top-posting
