Strawman: merge main and universe

Mark Shuttleworth mark at
Tue Dec 18 14:38:30 UTC 2007

Scott James Remnant wrote:
> The distinction between main and restricted is done based on licensing:
> software in main fulfils the necessary freedoms for modification and
> redistribution, software in restricted may not.
> I therefore propose an alternative.
> 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.
I think separately-maintained metadata is the right way to solve the 
problem of "what are we communicating about package X". Even components 
fail to communicate tricky things like the difference in maintenance 
windows for desktop and server on an LTS release - gnome-gpg is in main, 
and apache is in main, but they are "formally maintained" for different 
lengths of time, and there's no way to have the system generate a report 
of that for you.

Metadata, published separately and used by the full set of apps that 
need to communicate this to the end-user, would be a good solution.

> What about upload privileges?
> Let's do those the same way.
-1, and loudly.

I do think we need a richer privileges system for upload - we 
specifically need to solve the problem that people who care about a 
package in universe don't lose the ability to tend to it when it moves 
to main. But that should be the exception, rather than the rule. In 
other words, I would layer explicit additional permissions for packages, 
and (small) sets of packages, on top of our existing main/universe 
permissions. That way, when a package, or small set of tightly-linked 
packages, wants to migrate from universe to main, it can come with a 
dedicated group who can continue to upload to it even though it's in main.

I don't want to see a general move to seed-based permissioning, because 
while the seeds themselves are relatively stable, their dependencies can 
flap all over the show, and I don't want to have to try to resolve those 
issues, nor do I want people to have any incentive to define 
dependencies to achieve ulterior policy goals.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Ubuntu-devel-discuss mailing list