The 2 big meta packages (ubuntu-desktop and ubuntu-base) are very handy for easy installing and upgrading ubuntu. However it's not completely easy to choose only parts of the ubuntu-desktop packages. e.g. I want to just install gnome from ubuntu-desktop.

If you check out the seed at http://people.ubuntu.com/~cjwatson/seeds/hoary/desktop you'll see that it's divided into headings like: printing, fonts, desktop gnome fonts, gstreamer, python.

I'd like to suggest that instead of ubuntu-desktop depending on ~100 packs, it depends on a couple of meta packages to ease both maintainership and installing. We don't have to go overboard with this, but a couple of these I think would be a good idea.

e.g. all the python stuff can go into something like ubuntu-desktop-python or ubuntu-python and the gnome stuff into a similar package that ubuntu-desktop would depend on. So ubuntu-desktop could depend on ubuntu-desktop-python (you can call it whatever you think is a good name, just an example).

The original idea of these packages was to represent the seeds, and thereby ease upgrading when the seeds change. I'm a bit wary of creating a tree of metapackages as a means of high-level package selection; this was found to be suboptimal in Debian in the past.

Maybe we should take a step back, describe the use case, and consider alternative technical solutions to satisfy it.

The guiding principle should be "KISS". In the common case, users should not even be aware of these metapackages; they're a background mechanism for keeping the package selection up-to-date. Users shouldn't generally install or remove them unless they know exactly what they want, in which case they can manage their own package selections.

Currently, we offer two options:

• use the default package selection (and optionally add to it), receiving automatic updates to the default selection when they occur
• manage your own package selection, and take responsibility for keeping up with changes yourself (by reading release notes, mailing lists, checking the metapackages by hand, etc.)

What you're proposing is a third option, positioned between these two. So far, I'm not convinced that the trade-off is in our favour: complexity (in the packaging system and for the user) versus providing some users with a "halfway" option for managing package selections.

Why not package Live CDs with an extra Net-Install boot menu option and a Net-Install Gnome GUI frontend? For those of us wanting Live CDs, an extra couple megs (10-20?) won't matter; for those of us installing, an install from net is usually sufficient.

I think this would be nice as well because you could have a special install-to-GUI mode to get up while still installing. In this mode, you go as far as to partition the disk, select mount points, and create a user. Then /home is mounted, and the installer exits.

Once this is done, the Live CD could have a copy of the user account created in the Live CD /etc/passwd. The user would then get pushed into the Live CD (X/Gnome). A gnome-session wrapper (or whatever is appropriate) would detect if this was being done, and would additionally start up the installer using a Gnome interface (doesn't Debconf allow this?) and pick up where it left off.

Once the user is done using the GUI installer to the point that it's downloading and unpacking packages, he can switch desktops and do something in a fully functional Ubuntu environment while Ubuntu installs. He'll be working directly on what will become his /home directory, so it's like Ubuntu is already installed.

When the installation is finished, the user can reboot into his new system. Optionally, all installation tasks could be completed from the Live CD so that a reboot wouldn't require 10 minutes of waiting.

Bug #1956 deserves a public discussion, so let's do that here.

Gnome proper offers a so-called "autorun" feature for removable media. If enabled in gnome-volume-manager (disabled by default), g-v-m checks if a file "autorun" or "autorun.sh" is present and executable on newly mounted media. If so, the file is automatically executed.

However, since pmount mounts non-fstab drives with "noexec", this currently fails. So the question arises what we want to do with autorun in the future. I see the following options:

1. Completely disable: pmount with noexec (as now), remove the configuration option from gvm
2. enable: pmount with exec (should work automatically then)
3. enable with confirmation dialog: pmount with exec, change g-v-m to confirm execution

I don't really like 3 because confirmation dialogs tend to get ignored and they do not tell you what exactly will be performed anyway. I doubt that many users would want to actually read the shell code (let alone analyze a binary) before executing it.

My personal preference is option 1.

It should be noted that our only use case so far - automatic Ubuntu CD upgrades - does not need this feature. This was solved by a HAL script that checks whether an inserted CD is an Ubuntu one.

Thanks for the numerous replies to the discussion.

It seems that we should not completely drop this feature, but it should default to "off" in any case.

I recently tried this out again, Gnome already shows a confirmation dialog before executing the autorun file. So for maximum upstream compatibility I will implement option 3.

I will modify pmount soon to have a new switch -e/--exec which mounts a device with the 'exec' flag. Also, I will modify gnome-volume-manager to pmount with -e if the autorun feature is enabled.

Andreas and I spent some time hacking on the live CD today, and it's starting to come together. As many of you know, we've redesigned the live CD from scratch for Hoary, to simplify maintenance and to provide a base for some interesting new features. Here's what works so far:

• Boot into d-i
• Set up the live filesystem
• Pivot into the live filesystem
• Create a user
• Configure GDM autologin
• Initiate a normal boot sequence
• Login as root (no password)

You'll find that it looks very much like a normal Ubuntu system (more so than the Warty live CD), and this is intentional. Whereas the old live CD used infrastructure derived from other live CD projects, the new design uses infrastructure from existing Ubuntu components (for example, for hardware detection), along with some completely new ideas.

Things which aren't finished yet include:

• There isn't much progress indication yet, and in some cases you may see a blue screen during much of the boot process. If you are seeing a blue or red screen for too long, switch virtual consoles with Alt+F1 and Alt+F2. This will be fixed.

• There is as yet no means to automatically generate a working X configuration. Daniel Stone is working on this. Currently, GDM startup is suppressed and the boot process ends with a text console login. If you'd like to try out a desktop session, run:

  dpkg-reconfigure xserver-xorg

  and answer the questions, then run /etc/init.d/gdm start

  I ran into a problem once where I needed to unload and reload the mousedev module in order to get the mouse working, but I haven't looked into it yet.

• The boot process asks a few too many questions. This will be fine-tuned as things proceed.

Get it here: http://people.ubuntu.com/~mdz/ubuntu-live/hoary-live-i386-alpha1.iso

and follow up here to let us know how it's working for you. It's based on a Hoary snapshot which was built by Andreas about one week ago, but we should be able to build daily images fairly soon.

After certain upgrades (most notably upgrades between Ubuntu releases), there are follow-up actions which should be taken by the user. These are not logically part of the upgrade, but should be dealt with at some point after the upgrade is complete.

A prime example is the UTFEightMigrationTool. During an upgrade from Warty Warthog to Hoary Hedgehog, the system will be configured such that UTF-8 encoding is available, and will be expected by applications per default. The user should switch to a UTF-8 locale, and possibly rename or re-encode files in order to achieve the best user experience. These things cannot be done in automated fashion during the upgrade, but must instead be dealt with interactively by the user.

Original Proposed Design

• Maintainer scripts invoke a program to register a hook (typically a shell script) to be run by the user
• update-notifier receives these registrations, and notifies the user that they are pending
• When the user elects to process pending actions, they are executed in sequence within the context of the desktop (and so can display a GUI, interact with the user, etc.)

Design Spec

• the directory /var/lib/update-notifier/user.d/ is used to store hooks
• a hook file looks follows rfc822 rules:
  • a fieldname may have a "-$locale" in it. This is for i18n.
  • each hook must have a unique "Name" key and a "Description" key
  • a optional "Priority" with critical, high, medium, low that gives the user a idea how important the hook is
  • a optional "Command" field may be registered with a shell-command that the user can run (e.g. a script in /usr/lib/update-notifier/user.d/)
  • a optional "Terminal: True" field if the command should be execute in a terminal
• update-notifier will use gamin to scan /var/lib/update-notifier/user.d/ and show a small information icon for hooks it has not seen yet
• when the user clicks on the icon the name and description is given. If a shell script is registered, it asks if it should run that script.
• the encoding of the i18n fields is UTF-8

Status

• Basic support implemented in update-notifier 0.38
• Missing: i18n (-$locale), mtime check of the hook file

Example:

Name: The great UTF-8 Migration
Name-fr: Le grande UTF-8 Migrationé
Name-de_DE: Die große UTF-8 Migration
Priority: Medium
Command: bc
Terminal: True
Description: This command will convert your stuff into UTF-8.
 Use this command if you want a working gnome desktop and you
 feel the world should be a better place.

I've just finished writing up the summary of this Tuesday's (January 11, 2005) meeting of the Ubuntu Community Council. Information is available here:

Meeting on January 11, 2005:

• Summary: http://people.ubuntulinux.org/~mako/cc-summary-20050111.html
• Full Log: http://people.ubuntulinux.org/~mako/cc-meeting_log-20050111.html

The meeting covered a number of issues but there are two major issues which are of particularly noteworthy:

• The Council talked about new Local Community Teams (previously called Country Teams and now called LoCo Teams for short) for promotion of Ubuntu in particular locales. Folks wanting to get involved should read the log of the meeting and get in touch with Matthias Urlichs <smurf@smurf.noris.de> and myself.
• The council talked about the need to get community members involved in a contributing to and maintaining pieces of Universe. There is more information on this in the log and what to do if you'd like to get involved in Ubuntu in this way.

What do people think of having architecture-specific sections on the wiki? At the moment, there doesn't seem to be a PPC section (gathering together, e.g., one-button mice, mac on Linux, yaboot etc) or an AMD64 section. It would be easier for

Developing from this, what of having a version of ubuntu-in-a-nutshell tailored for PPC users? It shouldn't require too much work - much of the material can simply be reused without any changes - but would help with clarity and relevance.