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.
[snip]
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.
[snip]
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.
Mark
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
