I've been very tempted to adopt aptosid (replacing my Debian testing installs), but I've remained reluctant mostly because of the somewhat cumbersome way that package management needs to be handled in aptosid. To that end, tonight I wrote a script to streamline the process for "recognize rather than memorize" idiots like me. I am currently testing it on a sample aptosid install, and I'm thinking that other users (and users yet to come?) may have use for it. I call it 'apter'.

The script behaves differently depending on whether it's called by a user or by root. This reduces the number of commands that the user needs to memorize to one. I'm assuming that it's installed in /usr/local/bin. It's used as follows:

As a regular user logged into an X session, start 'apter'.

In the window that appears, enter the names of the packages you want to add to your system separated with spaces. (Note: You can copy&&paste package names from synaptic, a Web browser, etc.)

Click OK. (Note: When you click OK, the names you entered will be written to a temp file.)

A window appears that tells you what you need to do next to complete the process; namely it instructs you to:
1. Type 'Ctl-Alt-F1'.
2. Login as root.
3. Enter the 'apter' command and follow the prompts.

When you run the 'apter' command as root, it:

Goes into textmode ('init 3')

Asks you if you want to update.

Asks you if you want to upgrade.

Asks you if you want to install the packages whose names you wrote to the temp file above.

Tells you what you need to do to restart X (i.e., 'init 5 && exit').

Since I'm not an apt or aptosid genius -- or any kind of genius for that matter -- I would really appreciate it if someone with more expertise had a look at the do_root function in the script to verify that there isn't anything really evil in there.

Ideally, the script in root mode should prevent execution unless the user 'Ctl-Alt-F1'ed first -- but I've yet to figure out if there's a way to figure that out.

There is really no need to leave X just to install a package or two. All the manual says is that you should do a dist-upgrade only out-of-X (aka 'init 3').

Further more your script doesn't do a 'apt-get update' - so you do it manual or what? - and instead a 'apt-get upgrade' which the manual discourages…

In the end, i would not automate such a simple task given that automation usually leads to a more sloppy user-behavior and that is exactly what you don't want as we require users to think about and after that confirm the 'apt-get dist-upgrade' question. Not just confirm it because it's the fourth question in a series of questions you usually press confirm anyway…

_________________MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor

Under the heading "Installing a new package", the manual states, "Upgrading packages and installing new packages without stopping X can cause problems. Any method of installing packages under X has this problem. ... If you are in any doubt ensure you leave X as per the dist-upgrade instructions before installing any packages."

DonKult wrote:

Further more your script doesn't do a 'apt-get update'

Thanks for catching that! Line 102 should be 'apt-get update'. (Note the question asked on line 100.)

DonKult wrote:

we require users to think about and after that confirm the 'apt-get dist-upgrade' question. Not just confirm it because it's the fourth question in a series of questions you usually press confirm anyway…

Isn't doing regular and frequent dist-upgrades a part of standard hygiene? I'm in the process of adding a "Show upgrade warnings" button to the user ui to (1) remind users to check and (2) make it easy to check for those problems.

If doing frequent and non-deeply-introspective dist-upgrades is really an issue, it's easy enough to make it default to 'no'.

Under the heading "Installing a new package", the manual states, "Upgrading packages and installing new packages without stopping X can cause problems. Any method of installing packages under X has this problem. ... If you are in any doubt ensure you leave X as per the dist-upgrade instructions before installing any packages."

The keyword here is 'can' and what you generously hide in '...'. Specifically the "As long as any package you want to install will not upgrade additional packages then it is safe to install it without stopping X." If you dist-upgrade only once in a blue moon, a new KDE version is incoming, you want to upgrade kmail alone, yeap, that can cause trouble, but installing a leaf package like a game or some productive application is fair game…

Still not convinced that such a tool is such a good idea, but still a few comments:
* you can detect if you are on a tty - just check that the /proc/self/fd/0 is a link to /dev/tty? rather than a /dev/pts/? -- this would rule out ssh logins through, so it should only be a strong warning. Another option is to have a closer look at the who output, it tells you from there a user is logged in.
* The check for logged_in fails if the username sorts behind root. 'wc' for counting lines is a better idea.
* Running apt-get clean unconditional is a bad idea as it removes the chance to find an (old) working version of a package locally in case of problems with the new version.
* also, you handle multiuser systems (login status) but assume that only one person (marks for) installing stuff. As the file isn't protected link-attacks are properly possible and on a multiuser system it should be easy for a user who isn't root to become it just by pasting whatever he needs into this file before it is created by the user who will later install stuff. I could imagine creating the file with the content '-y --force-yes libc6-' and set it to world-writable. Okay, the user adding new packages to it will see that, but if i am good at timing (or use a script) i can create the file first empty, wait for the user adding some packages and then change it to my content (inotify to the 'rescue'). And thats only a very simple create maximum damage idea. With more thinking, we can do more subtil attacks…

apt-get has a dselect-upgrade command, i have never used it (which is an answer for itself), but marking packages with dpkg feels alot cleaner than reading it from a not-so-special file. I don't know about dependency resolution of this command through, so this remark is maybe completely pointless. I am too lazy now to check the code.

_________________MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor

@DonKuit: Thanks for all your comments. I'll work on making changes for your first three points -- those are fairly straight forward.

For the fourth, it looks like the "user" version should be run as root as well, and the file it creates be in a dir w/ root-only write access. Running both faces (X and textmode) as root might open up other possibilities as well, like doing --download-only while still in X to minimize time spent out of your X session.