Written by EVVK the 16 May 13 at 07:49.

One idea would to go over to BTRFS and use snapshots like apt-btrfs-snapshot or any other framework. Integrate snapshot selection that is easily reachable and understandable to a menu during bootup, like grub but it currently only shows some cryptography for non-technical users.

Dates are easy for example. Not that you sometimes need to press ESC or Shift to get into grub menu and choose advanced and then see more cryptic kernel version numbers.

One idea would to go over to BTRFS and use snapshots like apt-btrfs-snapshot or any other framework. Integrate snapshot selection that is easily reachable and understandable to a menu during bootup, like grub but it currently only shows some cryptography for non-technical users. Dates are easy for example. Not that you sometimes need to press ESC or Shift to get into grub menu and choose advanced and then see more cryptic kernel version numbers.

Written by snake444 the 20 Mar 13 at 07:28.

Like if your caps lock is on, it writes you that your caps lock key is on. so just write like this: Your typing language is : English.

Like if your caps lock is on, it writes you that your caps lock key is on. so just write like this: Your typing language is : English.

Written by chrisxsterling the 4 Apr 13 at 07:19.

Add an option to allow the Universal Access icon to display the current language in the form of a flag or abbreviated text.
Note: I use GNOME3 so I am used to seeing that icon up in the corner and thought that would be appropriate.

Add an option to allow the Universal Access icon to display the current language in the form of a flag or abbreviated text. Note: I use GNOME3 so I am used to seeing that icon up in the corner and thought that would be appropriate.

Written by zago84 the 22 Nov 12 at 13:32.

I think it's really useful if during upgrade process, by a drop-down menu in the same update manager window, you can choose the behavior before the end one of them:

- no action
- restart
- turn off

I thought about a drop-down menu that allow you to change your choice at any time during upgrade. Or more simply and less invasively a drop-down menu hidden under a simple icon like a gear.

So, after starting update process, you can get away from the PC and it will do what you choose.

I think it's really useful if during upgrade process, by a drop-down menu in the same update manager window, you can choose the behavior before the end one of them: - no action - restart - turn off I thought about a drop-down menu that allow you to change your choice at any time during upgrade. Or more simply and less invasively a drop-down menu hidden under a simple icon like a gear. So, after starting update process, you can get away from the PC and it will do what you choose.

Written by mikysett the 3 Dec 12 at 16:57.

If the size of the upgrade is really big, when you click on "update" a pop-up will appear telling: "Download and install all this stuff will take a lot of time for me, perhaps you wont be there then anymore, do you want I shoot down automatically when I've done?", with "yes", "no" and "config" buttons.
With this solution you can add in the parameters the minimum size of the download to make the pop-up appear.

So people can make the choice they want without having additional buttons to care about.

If the size of the upgrade is really big, when you click on "update" a pop-up will appear telling: "Download and install all this stuff will take a lot of time for me, perhaps you wont be there then anymore, do you want I shoot down automatically when I've done?", with "yes", "no" and "config" buttons. With this solution you can add in the parameters the minimum size of the download to make the pop-up appear. So people can make the choice they want without having additional buttons to care about.

Written by barrientosa the 14 Apr 12 at 06:14.

I think it's nice to show a message to users in case of failure, however it would save time if the update-manager can just check other servers around if your local mirror is overloaded and proceed with the upgrade silently without bothering you.

Nevertheless as a last resource I agree that update-manager should show some sort of message to the user, but only in case that all the mirrors are collapsed or something like that.

I think it's nice to show a message to users in case of failure, however it would save time if the update-manager can just check other servers around if your local mirror is overloaded and proceed with the upgrade silently without bothering you. Nevertheless as a last resource I agree that update-manager should show some sort of message to the user, but only in case that all the mirrors are collapsed or something like that.

Written by puxkggn the 28 Apr 12 at 13:17.

Update manager should not be doing fall backs something without showing a message to the user that it does.
In this case the Update manager should pick another one until it has either found a working mirror or doesn't find one.
In the found a working mirror it displays a message to the user while continuing. (The message is for information not for confirmation.) And in the latter it's of course impossible to continue.

Update manager should not be doing fall backs something without showing a message to the user that it does. In this case the Update manager should pick another one until it has either found a working mirror or doesn't find one. In the found a working mirror it displays a message to the user while continuing. (The message is for information not for confirmation.) And in the latter it's of course impossible to continue.

Written by Aielyn the 4 Oct 12 at 12:34.

While Solutions #1 and #2 are good in general, it is not always appropriate to have the update manager automatically pull files from an alternate mirror without allowing the user input.

For instance, for some, there are limits to downloads from most mirrors, but unlimited downloads from certain ISP-related mirrors. This occurs with Telstra in Australia, where file downloads from the AARNet Mirror are unlimited. For large updates, a switch to a different mirror could result in a significant dent in the download limit for the user. However, for small updates, the user might not be overly concerned, and may allow it anyway.

Which of the approaches to use could be set on first use of the Update manager, with "Silent" being the default option (as many users do not require information on alternate mirror usage at all) and the other options being "Automatic", "Manual", and "Off", with obvious meanings.

While Solutions #1 and #2 are good in general, it is not always appropriate to have the update manager automatically pull files from an alternate mirror without allowing the user input. For instance, for some, there are limits to downloads from most mirrors, but unlimited downloads from certain ISP-related mirrors. This occurs with Telstra in Australia, where file downloads from the AARNet Mirror are unlimited. For large updates, a switch to a different mirror could result in a significant dent in the download limit for the user. However, for small updates, the user might not be overly concerned, and may allow it anyway. Which of the approaches to use could be set on first use of the Update manager, with "Silent" being the default option (as many users do not require information on alternate mirror usage at all) and the other options being "Automatic", "Manual", and "Off", with obvious meanings.

Written by josthohad the 9 Dec 12 at 12:22.

Postpone steps that require the user to answer questions. in the end of the installation ask all the questions at ones, and then perform the actions related to the questions.

Postpone steps that require the user to answer questions. in the end of the installation ask all the questions at ones, and then perform the actions related to the questions.

Written by okirmis the 16 Jul 12 at 15:28.

Use only texts like "Updating application (name)..." or "Installing system update..." (here without package name, would be too confusing) would make things a lot easier for newbies to understand. The Muon Software Updater in Kubuntu already shows how you can display the "real" appliction name in the updater and not the package name.

Use only texts like "Updating application (name)..." or "Installing system update..." (here without package name, would be too confusing) would make things a lot easier for newbies to understand. The Muon Software Updater in Kubuntu already shows how you can display the "real" appliction name in the updater and not the package name.

Written by puxkggn the 19 Jul 12 at 15:52.

What solution #1 does but with option to show detailed information. It should be possible for power users to see the details. A lot of newbies think hiding stuff makes them quicker/easier while they hide important information. This hiding leads to a false sense of knowing how it works. By hiding how things are going, false sense of knowing can continue to exist. While people who know what's going on know enough to not care about the details.

What solution #1 does but with option to show detailed information. It should be possible for power users to see the details. A lot of newbies think hiding stuff makes them quicker/easier while they hide important information. This hiding leads to a false sense of knowing how it works. By hiding how things are going, false sense of knowing can continue to exist. While people who know what's going on know enough to not care about the details.

Written by james_t the 20 Oct 09 at 22:58.

Add a tick box to the Software Sources - Update Tab which say:

"Automatically download and install updates when available".

Add a tick box to the Software Sources - Update Tab which say: "Automatically download and install updates when available".

Written by ToxN the 22 Oct 09 at 07:05.

A generalisation of that principle could be to have the choice between automatic install of :
- critical security updates (already done)
- bug correction updates
- feature implementation updates

A generalisation of that principle could be to have the choice between automatic install of : - critical security updates (already done) - bug correction updates - feature implementation updates

Written by zoubidoo the 4 Jan 11 at 13:29.

The kernel changelog should be machine-readable. Knowing what hardware you have, update-manager/apt could check whether the kernel update is relevant and only install if necessary.

Of course some updates affect all hardware, so of course the update is relevant in this case.

But a kernel update because of a fix to isdn drivers is of no relevance to most users. Since we know our platform's hardware it should be possible to determine relevance.

The kernel changelog should be machine-readable. Knowing what hardware you have, update-manager/apt could check whether the kernel update is relevant and only install if necessary. Of course some updates affect all hardware, so of course the update is relevant in this case. But a kernel update because of a fix to isdn drivers is of no relevance to most users. Since we know our platform's hardware it should be possible to determine relevance.

Written by amoalsale the 3 May 12 at 04:52.

a simple notification like
"Installing these updates will require reboot"
should be shown in advance.

a simple notification like "Installing these updates will require reboot" should be shown in advance.

Written by benoyanthony the 15 May 12 at 10:09.

Other than complete reboot, system should initiate service restart with confirmation from user.

Other than complete reboot, system should initiate service restart with confirmation from user.

Written by Stebalien the 8 Aug 09 at 19:41.

The apt repository system would have a changelog spec. An extra line would be added for each package in the Packages file in an apt repository. This line would read "Changelog: /path/to/packagename-version.changelog".

The apt repository system would have a changelog spec. An extra line would be added for each package in the Packages file in an apt repository. This line would read "Changelog: /path/to/packagename-version.changelog".

Written by nowhere the 21 Aug 09 at 21:34.

Include a one-click or shopping list style method to revert to the previously install package versions. Often, systems are "broken" by one update in a long list and this would aid both in restoring the system to a more operational state and allowing a one at a time update process to find the offending update.

Include a one-click or shopping list style method to revert to the previously install package versions. Often, systems are "broken" by one update in a long list and this would aid both in restoring the system to a more operational state and allowing a one at a time update process to find the offending update.