Strawman: merge main and universe
mdz at ubuntu.com
Fri Dec 14 14:30:06 GMT 2007
On Wed, Dec 12, 2007 at 10:24:56PM +0000, Scott James Remnant wrote:
> The distinction between main and universe is instead done based on
> "support". But what does this actually mean?
Our terminology on this needs a bit of cleanup, but the relevant distinction
here is "maintenance". This means that, for example, a security
vulnerability in the package will be fixed, and this is backed up by a
commitment from Canonical (which has dedicated resources to this
> What about support for fixing bugs? We actually don't like to do that
> very much, we only have limited updates to our stable release. This
> surprises most people who think this is what support means.
We do need to do a better job of both communicating our maintenance
practices and ensuring that they meet expectations. There is work in
progress to change this for 8.04 LTS.
> We move all packages from universe into main, and remove the universe
> component. Likewise packages from multiverse are moved into restricted,
> and multiverse removed.
> Instead, we define who provides what kind of support through meta-data.
> We have generated lists of packages already, the seeds. In fact, it's
> these seeds that (by a manual process) result in packages being divided
> between main and universe right now.
> So let's just use these to determine the types of support provided.
This seems sensible to me; Debian-style components are unwieldy to work
with, as they are closely tied to the way the archive is published. We
should be able to change a declaration of maintenance without moving files
around on a web server, and the placement of the files isn't a very good way
of communicating this information.
> Canonical can declare that it provides commercial support for the
> ubuntu-desktop, ubuntu-server, ubuntu-mobile and kubuntu-desktop seeds
> (and any others we support that I forgot). It can also declare what
> date that support ends.
> Other companies and groups can declare their own support based on the
> existing seeds, or just branch the bzr repository and make their own
> (the seeds are public, and the tool to generate complete package lists
> is also public).
> The Ubuntu Security team can declare which seeds they provide security
> support for at which levels.
> The packaging tools can then use this information to show appropriate
> information to the user; they'll know the package they are installing is
> supported for a further 12 months by Canonical, a further 18 months by
> another company or group; Security support is provided by the Ubuntu
> security team for 12 months and critical bug fixes are no longer
This is tricky. In order to be effective, this needs to be communicated all
the way from apt-cache up through gnome-app-install in a reasonably
> What about upload privileges?
> Let's do those the same way.
Sounds elegant enough, though I wonder about automatically granting upload
privileges based on a new dependency.
More information about the ubuntu-devel