Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Ubuntu Development (http://www.linux-archive.org/ubuntu-development/)
-   -   Strawman: merge main and universe (http://www.linux-archive.org/ubuntu-development/18426-strawman-merge-main-universe.html)

Scott James Remnant 12-12-2007 09:24 PM

Strawman: merge main and universe
 
I'd like to make a strawman proposal to be torn apart and burnt as
necessary: merge main and universe. I will try and explain my
rationale, and my alternate proposal.

(I'm subscribed to all of the mailing lists I'm posting to, please don't
Cc me if you're following up to one of them)


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.

It is simple to pick a component for the software, you simply read the
licence. It also makes sense for the components to be separate since it
allows users (and derivatives) to make a decision not to accept software
under restricted licence conditions.


The distinction between main and universe is instead done based on
"support". But what does this actually mean?

Canonical provides commercial support for all packages in main. Well,
that's not actually true: we don't provide commercial support for them
all.

More than that, this needlessly emphasises Canonical in the Ubuntu
community. Why can't another company or group provide support? Why
doesn't members of MOTU supporting the package mean it can move to main?

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.

Security support is another angle to take; and another bucket of worms.


So the distinction is actually quite blurry. Perhaps the separation
still makes sense for user choice? I don't this is true either.

We used to have only main and restricted enabled by default, users had
to deliberately enable universe to get the software from it. Some time
ago we changed this to instead be handled through the user interface,
declaring whether or not you'd receive this strange "support" for the
package or not.


And this still doesn't cover the fact that in just a few months time,
there will be a LOT of packages in the "main" component of a "supported"
release (dapper) that won't be "supported" anymore.


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.

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.

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
provided.


What about upload privileges?

Let's do those the same way.

Teams can approach the Technical Board for permission to own a
particular seed; if granted, their team has permission to upload any
package in the resulting list of packages from that seed.

(The seed system already has priorities, so you couldn't add a package
in ubuntu-desktop and take it over; at least, not without negotiation.)

The kubuntu-dev team could maintain (and support, etc.) Kubuntu.
xubuntu-dev could do the same for Xubuntu, and so on. To become an
uploader for Kubuntu, you would need to be granted permission from that
team, not from the Technical Board.

That team is better placed to judge your skills anyway.

We'd still need the existing two teams:

ubuntu-core-dev would have permission to upload to everything. It would
remain the ultimate accolade technical team, and membership would be
available to anyone who has excelled in

ubuntu-dev, which would have permission to upload to anything not
seeded, and would be members of most of the other technical teams as
well. This is where you would graduate to after being a member of a
specific team.


Like I said, it's a straw man. Please debate, discuss, argue, but don't
flame :-)

Scott
--
Scott James Remnant
scott@ubuntu.com

--
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

Scott James Remnant 12-12-2007 09:24 PM

Strawman: merge main and universe
 
I'd like to make a strawman proposal to be torn apart and burnt as
necessary: merge main and universe. I will try and explain my
rationale, and my alternate proposal.

(I'm subscribed to all of the mailing lists I'm posting to, please don't
Cc me if you're following up to one of them)


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.

It is simple to pick a component for the software, you simply read the
licence. It also makes sense for the components to be separate since it
allows users (and derivatives) to make a decision not to accept software
under restricted licence conditions.


The distinction between main and universe is instead done based on
"support". But what does this actually mean?

Canonical provides commercial support for all packages in main. Well,
that's not actually true: we don't provide commercial support for them
all.

More than that, this needlessly emphasises Canonical in the Ubuntu
community. Why can't another company or group provide support? Why
doesn't members of MOTU supporting the package mean it can move to main?

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.

Security support is another angle to take; and another bucket of worms.


So the distinction is actually quite blurry. Perhaps the separation
still makes sense for user choice? I don't this is true either.

We used to have only main and restricted enabled by default, users had
to deliberately enable universe to get the software from it. Some time
ago we changed this to instead be handled through the user interface,
declaring whether or not you'd receive this strange "support" for the
package or not.


And this still doesn't cover the fact that in just a few months time,
there will be a LOT of packages in the "main" component of a "supported"
release (dapper) that won't be "supported" anymore.


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.

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.

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
provided.


What about upload privileges?

Let's do those the same way.

Teams can approach the Technical Board for permission to own a
particular seed; if granted, their team has permission to upload any
package in the resulting list of packages from that seed.

(The seed system already has priorities, so you couldn't add a package
in ubuntu-desktop and take it over; at least, not without negotiation.)

The kubuntu-dev team could maintain (and support, etc.) Kubuntu.
xubuntu-dev could do the same for Xubuntu, and so on. To become an
uploader for Kubuntu, you would need to be granted permission from that
team, not from the Technical Board.

That team is better placed to judge your skills anyway.

We'd still need the existing two teams:

ubuntu-core-dev would have permission to upload to everything. It would
remain the ultimate accolade technical team, and membership would be
available to anyone who has excelled in

ubuntu-dev, which would have permission to upload to anything not
seeded, and would be members of most of the other technical teams as
well. This is where you would graduate to after being a member of a
specific team.


Like I said, it's a straw man. Please debate, discuss, argue, but don't
flame :-)

Scott
--
Scott James Remnant
scott@ubuntu.com

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

"Emmet Hikory" 12-12-2007 09:52 PM

Strawman: merge main and universe
 
On Dec 13, 2007 7:24 AM, Scott James Remnant wrote:
> I'd like to make a strawman proposal to be torn apart and burnt as
> necessary: merge main and universe. I will try and explain my
> rationale, and my alternate proposal.
<...>
> The distinction between main and universe is instead done based on
> "support". But what does this actually mean?
<...>
> 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.
>
> 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.

Seeds make a lot of sense in this case, and also saves the issues
with MainInclusionReports: those with access to the seed are able to
adjust the content of the seed, following the guidelines for a given
seed.

<...>
> What about upload privileges?
>
> Let's do those the same way.
>
> Teams can approach the Technical Board for permission to own a
> particular seed; if granted, their team has permission to upload any
> package in the resulting list of packages from that seed.
>
> (The seed system already has priorities, so you couldn't add a package
> in ubuntu-desktop and take it over; at least, not without negotiation.)
<...>
> ubuntu-dev, which would have permission to upload to anything not
> seeded, and would be members of most of the other technical teams as
> well. This is where you would graduate to after being a member of a
> specific team.

I see three issues with this model, as follows:

A given seed may contain packages that are also in other seeds,
for example the UbuntuStudio Desktop seed contains many of the same
packages as the Ubuntu Desktop seed. By allowing upload to anything
in a seed by those belonging to a seed-managing team, the core
packages (e.g. udev) will have a large number of uploaders, whereas
edge packages interesting to only one team (e.g. mythweather) will
have a very small number of uploaders. To me this seems an imbalance:
I'd think edge packages should encourage a wider number of
contributors to look at them, and core packages should have a more
focused group.

Any team which wished to have a set of seeds that resulted in an
installation CD would necessarily need access to installation tools,
core applications, etc. As a result, the barrier for entry for
derivatives would be much higher. In the current state, a derivative
need only get inclusion of the meta-packages in Ubuntu, get installer
patches accepted, and be granted CD builds. With a seed-based
permission system, all members of the derivative development team
would need to be reviewed to ensure that they should be granted access
to all packages identified in the seed. This makes it harder for a
small group on the periphery of Ubuntu development to establish an
alternate focus, and build a related development community.

As the number of seeded sets grows, the set of packages managed by
~ubuntu-dev shrinks, perhaps encouraging the definition of seeds to
ensure continued ability to upload to packages of interest (e.g. MOTU
Science, or MOTU Games, etc.). This further splinters the archive
permissions, possibly to a point where members of ~ubuntu-dev only
have access to essentially unmaintained software. While this is
interesting from a package maintenance point of view, it represents
significant changes to the recruitment processes, and breaks the
current sponsoring model (unless all sponsors are chosen from the
ranks of ~ubuntu-core-dev).

--
Emmet HIKORY

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Scott James Remnant 12-12-2007 11:18 PM

Strawman: merge main and universe
 
On Thu, 2007-12-13 at 07:52 +0900, Emmet Hikory wrote:

> Seeds make a lot of sense in this case, and also saves the issues
> with MainInclusionReports: those with access to the seed are able to
> adjust the content of the seed, following the guidelines for a given
> seed.
>
I think we'd probably still have something very much like those. An MIR
right now is permission to add your package to one of the seeds (which
determine the set of packages in main).

With my strawman model, you'd still need some kind of permission to
change a seed, so the MIR still fits. The seeds still determine who
supports and who can upload to the packages, as they do now. It's just
finer grained and gives precise answers.

(The difference being that the seed owners may set their own
permissions; the primary seeds that currently determine what goes in
main would probably keep the same work flow as they do today, the only
difference being that the archive admins don't need to change a
component after committing the seed change).

> A given seed may contain packages that are also in other seeds
>
Ah, I perhaps assumed a little too much knowledge of the seed system. I
suggest people read https://wiki.ubuntu.com/SeedManagement for more
details.

This is already handled in the seed model. Seeds are built and based on
other seeds, and have inherent priorities.

If a package seeded in the standard seed is also seeded in the desktop
seed, then it only appears in the standard package list -- since
standard trumps it. Likewise for dependencies, if a seeded package in
standard depends on a package seeded in desktop, it's actually promoted
to standard. You see output like the following from germinate:

! Promoted dmidecode from standard to minimal to satisfy laptop-detect

So since the core packages like udev are seeded in a higher priority
seed like standard, then those packages are owned by their owning team
(core-dev) not by the final derivatives.

This means that making a new derivative is as simple as creating a seed
and deciding where it derives from; desktop or standard most likely.
You then get upload rights to the packages unique to your set, where you
have overlap, the higher priority seed wins (which may simply be the
first alphabetically) -- at that point rights have to be negotiated, and
the TB can step in and help (probably by suggesting a common base seed).

> As the number of seeded sets grows, the set of packages managed by
> ~ubuntu-dev shrinks
>
This is covered in the straw man. ubuntu-dev would be a member of the
individual teams like kubuntu-dev, xubuntu-dev.

This means there's only ever one team in charge of a particular package.
Picking on some examples:

epiphany is part of the gobuntu seed
gobuntu is owned by gobuntu-dev
thus epiphany can be uploaded by gobuntu-dev

ubuntu-dev is a member of gobuntu-dev by policy

ubuntu-core-dev is a member of ubuntu-dev
thus epiphany can be uploaded by ubuntu-core-dev

motu is a member of ubuntu-dev
thus epiphany can be uploaded by motu

People that can upload epiphany: gobuntu-dev, ubuntu-core-dev, motu


udev is part of the minimal seed
minimal is owned by ubuntu-core-dev
thus udev can be uploaded by ubuntu-core-dev

People that can upload udev: ubuntu-core-dev


doomtetris is not seeded
not seeded packages are owned by ubuntu-dev

ubuntu-core-dev is a member of ubuntu-dev
thus doomtetris can be uploaded by ubuntu-core-dev

motu is a member of ubuntu-dev
thus doomtetris can be uploaded by motu

People that can upload epiphany: ubuntu-core-dev, motu


So MOTU would have the rough privilege it has today; it's package set
may actually increase a little bit in fact as the "fight to get into
main" has gone away and we're all sharing a single component.

The primary change is that teams like kubuntu, MOTU Science, etc. can
exist with actual upload rights of their own and nurture their own
developers; and those developers can graduate to MOTU proper, and then
eventually to ubuntu-core-dev.

Scott
--
Scott James Remnant
scott@ubuntu.com
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

"Emmet Hikory" 12-13-2007 01:07 AM

Strawman: merge main and universe
 
On Dec 13, 2007 9:18 AM, Scott James Remnant wrote:
> On Thu, 2007-12-13 at 07:52 +0900, Emmet Hikory wrote:
> > Seeds make a lot of sense in this case, and also saves the issues
> > with MainInclusionReports: those with access to the seed are able to
> > adjust the content of the seed, following the guidelines for a given
> > seed.
> >
> I think we'd probably still have something very much like those. An MIR
> right now is permission to add your package to one of the seeds (which
> determine the set of packages in main).
>
> With my strawman model, you'd still need some kind of permission to
> change a seed, so the MIR still fits. The seeds still determine who
> supports and who can upload to the packages, as they do now. It's just
> finer grained and gives precise answers.
>
> (The difference being that the seed owners may set their own
> permissions; the primary seeds that currently determine what goes in
> main would probably keep the same work flow as they do today, the only
> difference being that the archive admins don't need to change a
> component after committing the seed change).

Yes. This seemed to be the primary advantage: a given team would
be able to process the changes directly (by whichever is their
preferred workflow) without requiring intervention of the archive
administrators, which significantly reduces the pain of moving things
in and out of seeds. For Ubuntu-desktop related seeds, the workflow
would likely stay the same, but other teams may select other
workflows, and the archive-admins do not have extra work due to the
addition of more teams.

> > A given seed may contain packages that are also in other seeds
> >
> Ah, I perhaps assumed a little too much knowledge of the seed system. I
> suggest people read https://wiki.ubuntu.com/SeedManagement for more
> details.
>
> This is already handled in the seed model. Seeds are built and based on
> other seeds, and have inherent priorities.

I've just read through that page, and looked at some seeds. That
structure seems to be in place for minimal, standard, desktop, etc.
On the other hand, it doesn't currently appear to be in place for
mythbuntu or ubuntustudio. Maybe this is just documentation, or would
need to be part of a transition plan.

Alternately, I'd wonder how this would work for things like
Xubuntu, where many of the packages to be seeded would also be part of
desktop. Would desktop take priority? Who decides which seed takes
precedence in cases of sharing? Would this result in the definition
of new seeds for shared areas of interest?

> > As the number of seeded sets grows, the set of packages managed by
> > ~ubuntu-dev shrinks
> >
> This is covered in the straw man. ubuntu-dev would be a member of the
> individual teams like kubuntu-dev, xubuntu-dev.

Excellent. My misinterpretation. This addresses my concerns
about splintering the repositories and sponsoring.

> So MOTU would have the rough privilege it has today; it's package set
> may actually increase a little bit in fact as the "fight to get into
> main" has gone away and we're all sharing a single component.

It actually sounds like it significantly simplifies workflow for
MOTU, as there would no longer be a need to balance the advantages of
pushing to main with the inconvenience of losing upload rights as a
result, and individuals with interest in specific areas traditionally
in main would be able to join that team without needing to be a member
of core-dev directly.

> The primary change is that teams like kubuntu, MOTU Science, etc. can
> exist with actual upload rights of their own and nurture their own
> developers; and those developers can graduate to MOTU proper, and then
> eventually to ubuntu-core-dev.

Phrased that way, it seems to actually improve the options
available for recruitment and sponsoring, rather than interfere. I'm
not sure that all new developers should "graduate" to MOTU if their
primary interest is team-specific: I can well imagine a developer
actively working on Ubuntu desktop who is not a member of MOTU (and
thereby ~ubuntu-dev), yet whose work is unimpeded by this. On the
other hand, with such a group-managed repository, it may make sense
for first being MOTU to become a requirement for gaining core-dev, as
a means of demonstrating restraint when granted access to packages not
specific to areas of interest.

--
Emmet HIKORY

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Ted Gould 12-13-2007 05:59 AM

Strawman: merge main and universe
 
On Wed, 2007-12-12 at 22:24 +0000, Scott James Remnant wrote:
> So the distinction is actually quite blurry. Perhaps the separation
> still makes sense for user choice? I don't this is true either.
>
> We used to have only main and restricted enabled by default, users had
> to deliberately enable universe to get the software from it. Some time
> ago we changed this to instead be handled through the user interface,
> declaring whether or not you'd receive this strange "support" for the
> package or not.

This may be more true in the future. With PolicyKit, perhaps a
progressive administrator would allow users to install anything on their
machines that is in main, but not Universe or PPAs.

I think for many folks that are less familiar with Linux and don't live
it day in and out (like the folks on this list) they want a set of
"good" applications. I relate this to my friend David Uhlman who every
year gives a "top applications on Linux" talk at SCALE. I think it's
the most boring thing ever, I tried to talk him out of doing it. He
consistently wins honors for being voted a top talk of the conference.

I guess we can look at "main" as the "Editor's Choice" of everything
that is in Universe. The best applications at solving problems of
users.

Now, I like the idea of organizing users based on seeds, but I think
users would miss having a "best" or "more reviewed" category of
packages.

--Ted

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Daniel Holbach 12-13-2007 07:13 AM

Strawman: merge main and universe
 
I generally like the proposal and think that it will make us more
flexible in the long run.

On Mi, 2007-12-12 at 22:24 +0000, Scott James Remnant wrote:
> 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.
>
> 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.

I think it will be more complicated for customers to figure out what
actually is supported, also a bit more complicated to figure out for new
users who to turn to get changes included or involved in some team.


> Teams can approach the Technical Board for permission to own a
> particular seed; if granted, their team has permission to upload any
> package in the resulting list of packages from that seed.
>
> (The seed system already has priorities, so you couldn't add a package
> in ubuntu-desktop and take it over; at least, not without negotiation.)
>
> The kubuntu-dev team could maintain (and support, etc.) Kubuntu.
> xubuntu-dev could do the same for Xubuntu, and so on. To become an
> uploader for Kubuntu, you would need to be granted permission from that
> team, not from the Technical Board.

Will people who want to help out with xubuntu-dev have to go through the
MOTU process first? If not, I'd suggest that the team who approves a new
uploader should have an established Team Council
(http://wiki.ubuntu.com/CommunityCouncil/Delegation), and reports to the
CC and TB.

Have a nice day,
Daniel



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Martin Pitt 12-13-2007 07:58 AM

Strawman: merge main and universe
 
Scott James Remnant [2007-12-13 0:18 +0000]:
> (The difference being that the seed owners may set their own
> permissions; the primary seeds that currently determine what goes in
> main would probably keep the same work flow as they do today, the only
> difference being that the archive admins don't need to change a
> component after committing the seed change).

I always have considered that a good feature actually. It's the only
point where we control what actually goes in and out of a component
like main. If we lose that, then any transitive dependency addition
would automatically get supported. If it was not a manual merge, but
an autosync, then there are no humans involved at all any more. Thus
you end up with many packages we do not actually want to support in a
particular seed.

E. g. libssh2 (#173783) was introduced in a curl merge, but it's
something we do not want to support for 5 years without at least
making a qualified decision about it.

Can we create one component per product instead of melting all
products into main? I understand that this might break the ogre model
in interesting ways and would also furtherly complicate apt sources
like

main restricted universe multiverse

becomes

ubuntu ubuntu-restricted kubuntu kubuntu-restricted universe

if someone wants to use ubuntu and kubuntu on his box (assuming
'universe' continues to be a catch-all for packages not seeded
anywhere). But that could also nicely be hidden in our package
management tools. AFAIU you, you want them to be extended like

Products: [x] Use software with restricted licenses
[x] Ubuntu
[ ] Kubuntu
[x] Edubuntu
[ ] Xubuntu

anyway, right? It would be easier to map this to particular apt
sources than to find out on the client side which seed a particular
package belongs to.

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Kees Cook 12-13-2007 05:58 PM

Strawman: merge main and universe
 
Hi,

On Wed, Dec 12, 2007 at 10:24:56PM +0000, Scott James Remnant wrote:
> Security support is another angle to take; and another bucket of worms.

What gets security support[1] is a list of packages. I personally don't
care what that list is called, as long as the contents don't change
suddenly, and there is still a manual process that allows packages to
get on the list. I'd propose the following requirements for implementing
the suggested change:

- Whatever seeds end up being defined as "security-supported" should not
differ in content much from the current list of packages in "main".

- As mentioned by Martin, the process for a package crossing over into
the security-supported seeds must be manual, and the approval process
should be as strict as current MIR.

- The list of supported packages should be easy for an end-user to
query. From some of the other threads on this subject, it sounds like
making the package list discoverable is critical to the success of the
plan. And I think this method needs to be separate from Launchpad --
a server admin studying his system needs to be able to ask the
question "what packages do I have installed that are NOT supported?"
without making tons of queries to LP, doing arcane dctrl-greps, or
writing scripts to parse germinate output.

Beyond that stuff, I think it sounds like a great idea, even if it does
result in some higher complexity in places.

-Kees

[1] in this context, I mean "Canonical-sponsored security support".

--
Kees Cook
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Reinhard Tartler 12-13-2007 07:38 PM

Strawman: merge main and universe
 
Scott James Remnant <scott@ubuntu.com> writes:

> 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.

At the moment, packages in main cannot (build-)depend on packages in
universe. This is technically easy to implement with apt. What
consequences would your proposal have with respect to this constraint?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


All times are GMT. The time now is 02:09 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.