FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Development

 
 
LinkBack Thread Tools
 
Old 02-12-2009, 09:24 AM
Alexander Sack
 
Default apturl repository whitelist application process

Hi all,

One of the topics on the jaunty agenda was to come up with a process
document that defines how third party repositories can apply for
apturl whitelisting and how we can ensure that such repositories are
of high maintenance quality. Based on various discussions we drafted an
initial policy-like draft, which you can find below. Please comment.


== Application Guidelines ==
This policy governs inclusion of third party repositories that can
automatically be added to a user's sources list via an apturl
link. This will result in a user experience where certain third party
packages can be installed by clicking on a hyperlink, and then can be
automatically updated via the normal Ubuntu apt mechanisms.

Users benefit from having a small number of well maintained archives
to manage. Therefore, packages should be placed in the appropriate
official Ubuntu repository. This process is only for extreme
exceptions where inclusion in a Ubuntu repository is not feasible due
to licensing or technical issues.

=== Prerequisites ===
Before being considered for acceptance as a third party repository,
the project must meet the following prerequisites.

==== Formal Prerequisites ====
* In order to ensure transparency and to facilitate monitoring of
quality and the state of the repository, a launchpad project must be
maintained for the package. Each source package should have it's own
repository where appropriate.
* In order to assure that packages in third party repositories are
being properly maintained, each landing page that offers an apturl
link must also contain a prominent link for reporting bugs in the
related launchpad project.

==== Use-Case Prerequisites ====
* Only packages that are essential for fulfilling very common end
user use cases will be considered.
* Only packages where inclusion in the appropriate Ubuntu repository
is not feasible for some technical or licensing reason will be
considered.

=== Repository Quality Requirements ===
Users have a right to expect the same level of quality and stability
from packages installed via apturl as applications installed from
other methods. Therefore, third party repositories for stable Ubuntu
release _must_ deliver a stable user-experience comparable to those of
ubuntu standards.

Therefore:
* All applications must describe the procedures used by the archive
maintainer on how this level of quality will be achieved and
maintained.
* Applications should be able to demonstrate a track recode of robust
usage.
* All applications will undergo a review by the Ubuntu third party
application team. In case a rejection the team will provide a list of
problems identified and suggestions on how those can be fixed.
* Accepted repositories will undergo process similar to the ubuntu
SRU process to ensure. This includes reviews/testing in a staging
area documented in bugs.

=== Package Requirements ===
* Package namespace for the name should start with a unique prefix
and not conflict
with any existing name on the system
* File system layout of the package should be to install to /opt -
unless there is a good reason for individual files to be shipped
elsewhere.
* There must be no conflicting binary nor so names
* Identify third party repository by custom package/source control
field
* add XB(S)-ThirdParty-RepoURL to the package that is uniq to
identify where the master repo is
* Identify right place to file bugs by custom package/source control
field
* add XB(S)-ThirdParty-BugFileUrl to the package that points to the
bug report page (LP)

== Application Process ==

=== High Level Workflow ===
1. Application submission
1. Application review (~ubuntu-tpr)
1. Package review
1. Whitelist rollout
1. Regular quality reviews
1. Whitelist removal and blacklisting

In general, the process will be guided by ~ubuntu-tpr, though they may
ask other teams for reviews and support as needed.

=== Application Submission ===
To begin the process, the "driver" (owner) of the third party
repository applies for consideration by:
1. Filing an application as a bug against app-install-data package
using the ThirdPartyWhitelistApplicationTemplate
1. Subscribing the ~ubuntu-tpr team to the bug
1. Setting the bug to "Confirmed"

=== Application Review ===
Upon receiving an application a ~ubuntu-tpr team member will:
1. Review the application checking for adherence to the formal
prerequisites.
1. If the application does not meet the formal prerequisites
~ubuntu-tpr team member will ask for info and set to Incomplete. The
third party driver may then reapply, if desired.
1. If application does not meet Use-Case prerequisites, the bug is
marked as
invalid. Team member states reasons for rejection. The third party
driver

=== package review ===
Upon accepting an application, ~ubuntu-tpr will follow the package
review process by:
1. Reviewing Package Requirements (see above)
1. optionally subscribe to ~ubuntu-archive in case a general package
review or
second opinion is wanted
1. If accepted, the reviewer will set the state to fix committed when
ready.
1. If not accepted the reviewer will marked the bug as incomplete and
include the reason. Reason for not being accepted can include
concrete technical bits, but also a request to prove a track record.

=== whitelist rollout (development release) ===
In order for the third party repository to work with apturl, it will
need to be added to the white list,a nd the white list updated. If the
repository is being added to a release under development, the
whitelist will be rolled out as follows:
1. ~ubuntu-tpr team commits whitelist to app-install-data
1. ~ubuntu-tpr team targets bug for suitable ubuntu releases
1. ~ubuntu-tpr team to drive roll out of packages to current
development release

=== whitelist rollout (stable ubuntu releases) ===
If the repository is being added to a current stable release, then the
following process will be followed:
1. ~ubuntu-tpr team will regularly publish accumulated whitelist
changes to
UBUNTU-proposed/updates

=== Regular quality reviews ===
At a predefined interval, ~ubuntu-tpr will do a quality review of each
third party repository by:
* regular checks of the buglist to ensure that bugs are processed
and addressed.
* regular review of repository contents to ensure that no new
packages added without
approval.
* reviews will occur on an ongoing basis, but a good practice is to
ensure a review after beta, with the RC as the final deadline for
fixing bugs.

~ubuntu-tpr will also:
* ensure that all repos part of the regular uprade testing
* on upgrade bugs from third-party report add apport mechanism to
make them
easy to find

=== Whitelist removal and blacklisting ===
Users have a right to expect high quality ongoing support and a robust
user experience over time. Therefore, repositories may have to be
removed.

Repositories my be removed for the following reasons::
* The packages have not been updated for the upcoming release by beta
* Packages fail a quality review
* A breach of this policy

Depending on the problem a warning might be sent to the driver of the
package. For serious problem or violations, the repository may be
removed without warning. The repository will be removed by updating
the white list following the normal update process, though with the
repository removed from the list, rather than added. Note that this
will only remove apt-url support for new users. It will not remove the
repositories from the users' sources lists.

However, if necessary, the repository may actually be removed from the
users' sources lists. This may be necessary if there are severe
problems on the repository such as data lose errors, security
problems, repository maintainer is not cooperating. The repository can
not reapply for at least 1 year for inclusion again

Repositories in this manner will be removed in this manner by:
1. a security update is issued for app-install-data-partner that
removes the repository from the package
1. the sources.list from the users system is inspected for the
blacklisted repository and if its still in the users sources.list it
is removed and a notification (via update-notifier hooks) is
generated that tells the user about it.

~ubuntu-tpr determines necessary removal actions.

[1] - https://wiki.ubuntu.com/ThirdPartyRepositoryApplicationProcess


- Alexander Sack and Michael Vogt



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-12-2009, 08:35 PM
Scott Ritchie
 
Default apturl repository whitelist application process

Alexander Sack wrote:
> Hi all,
>
> One of the topics on the jaunty agenda was to come up with a process
> document that defines how third party repositories can apply for
> apturl whitelisting and how we can ensure that such repositories are
> of high maintenance quality. Based on various discussions we drafted an
> initial policy-like draft, which you can find below. Please comment.
>

> * In order to assure that packages in third party repositories are
> being properly maintained, each landing page that offers an apturl
> link must also contain a prominent link for reporting bugs in the
> related launchpad project.
>

At Wine, we would much rather they report bugs straight to our own bug
tracker, as only I look at the Launchpad bugs. I imagine other projects
may be the same way.

> ==== Use-Case Prerequisites ====
> * Only packages where inclusion in the appropriate Ubuntu repository
> is not feasible for some technical or licensing reason will be
> considered.

Do beta packages meet this description?

>
> === Repository Quality Requirements ===
> Users have a right to expect the same level of quality and stability
> from packages installed via apturl as applications installed from
> other methods. Therefore, third party repositories for stable Ubuntu
> release _must_ deliver a stable user-experience comparable to those of
> ubuntu standards.
>

Apparently not then. Apparently the goal is for a Wine PPA to take
over, which is fine I guess now that they're signed. The only thing I
really lose from all this is that I can no longer collect web statistics
on package downloads and such -- will Launchpad be providing any such
feature?

> === Package Requirements ===
> * Package namespace for the name should start with a unique prefix
> and not conflict
> with any existing name on the system
> * File system layout of the package should be to install to /opt -
> unless there is a good reason for individual files to be shipped
> elsewhere.

Some repos will want to replace system packages (eg medibuntu)...this
seems incompatible with these requirements.

> - Alexander Sack and Michael Vogt
>

Thanks for your work on this, by the way. This was indeed a problem
needing solving

Thanks,
Scott Ritchie

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-12-2009, 09:10 PM
Brian Thomason
 
Default apturl repository whitelist application process

First off, thanks to both of you for getting this done.* It's something we've wanted on the ISV side of things for a while now.





==== Formal Prerequisites ====

** In order to ensure transparency and to facilitate monitoring of

*quality and the state of the repository, a launchpad project must be

*maintained for the package. Each source package should have it's own

*repository where appropriate.
This would be a troublesome requirement for someone like google who maintains all of their apps in the same repo.
*


** In order to assure that packages in third party repositories are

*being properly maintained, each landing page that offers an apturl

*link must also contain a prominent link for reporting bugs in the

*related launchpad project.
What if the vendor prefers to handle all bugs through their own bug tracker?
*


** Package namespace for the name should start with a unique prefix

*and not conflict
Must we require a prefix when there is no chance of a natural collision? For instance, if google wants to ship google earth and the package name is google-earth, can we waive the prefix requirement?

*

** Identify third party repository by custom package/source control

*field

** add XB(S)-ThirdParty-RepoURL to the package that is uniq to

*identify where the master repo is

** Identify right place to file bugs by custom package/source control

*field

** add XB(S)-ThirdParty-BugFileUrl to the package that points to the

*bug report page (LP)


These seem a little onerous too.* If the control file already provides a website for the product, that should seemingly sufice as they are already required to have the bug tacker info prominently displayed there...?

*

However, if necessary, the repository may actually be removed from the

users' sources lists. This may be necessary if there are severe

problems on the repository such as data lose errors, security

problems, repository maintainer is not cooperating. The repository can

not reapply for at least 1 year for inclusion again


I don't think we should make the 1 year a steadfast rule, or at least shorten it dramatically.
*Again, thanks for the work guys.* It's looking good.

-Brian


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-13-2009, 10:09 AM
Alexander Sack
 
Default apturl repository whitelist application process

On Thu, Feb 12, 2009 at 05:10:07PM -0500, Brian Thomason wrote:
> First off, thanks to both of you for getting this done.* It's something
> we've wanted on the ISV side of things for a while now.
>
> ==== Formal Prerequisites ====
> ** In order to ensure transparency and to facilitate monitoring of
> *quality and the state of the repository, a launchpad project must be
> *maintained for the package. Each source package should have it's own
> *repository where appropriate.
>
> This would be a troublesome requirement for someone like google who
> maintains all of their apps in the same repo.

we appended the "where appropriate", which means that there might be
exceptions. It's just that we believe that its easier for both the
reviewers and the repository maintainers to provide dedicated apt
sources lines for each application they provide.

If they don't they cannot upload a new package to their (already
whitelisted) repository before getting a review on the package.


> *
>
> ** In order to assure that packages in third party repositories are
> *being properly maintained, each landing page that offers an apturl
> *link must also contain a prominent link for reporting bugs in the
> *related launchpad project.
>
> What if the vendor prefers to handle all bugs through their own bug
> tracker?
> *

I addressed that in my other reply to Scott..

>
> ** Package namespace for the name should start with a unique prefix
> *and not conflict
>
> Must we require a prefix when there is no chance of a natural collision?
> For instance, if google wants to ship google earth and the package name is
> google-earth, can we waive the prefix requirement?
> *
>

I would think that with "google-" we already have a prefix we could
use for that. It might be a bit special case as we already have google-
prefixed packages in the archive, but in general i don't see a problem
to use the vendor name for prefixing vendor hosted packages.


> ** Identify third party repository by custom package/source control
> *field
> ** add XB(S)-ThirdParty-RepoURL to the package that is uniq to
> *identify where the master repo is
> ** Identify right place to file bugs by custom package/source control
> *field
> ** add XB(S)-ThirdParty-BugFileUrl to the package that points to the
> *bug report page (LP)
>
> These seem a little onerous too.* If the control file already provides a
> website for the product, that should seemingly sufice as they are already
> required to have the bug tacker info prominently displayed
> there...?

Having the used bug database and the used repository in the control
file gives easy access for reviewers to all the most basic information
to get started.

Also later we could use the bug file url to automatically direct users
to that url if we encounter crash or something.

> *
>
> However, if necessary, the repository may actually be removed from the
> users' sources lists. This may be necessary if there are severe
> problems on the repository such as data lose errors, security
> problems, repository maintainer is not cooperating. The repository can
> not reapply for at least 1 year for inclusion again
>
> I don't think we should make the 1 year a steadfast rule, or at least
> shorten it dramatically.

I agree, we should address that.


- Alexander


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-13-2009, 10:16 AM
Alexander Sack
 
Default apturl repository whitelist application process

(resending to list ... forgot to hit the proper reply button )

On Thu, Feb 12, 2009 at 01:35:04PM -0800, Scott Ritchie wrote:
> Alexander Sack wrote:
> > Hi all,
> >
> > One of the topics on the jaunty agenda was to come up with a process
> > document that defines how third party repositories can apply for
> > apturl whitelisting and how we can ensure that such repositories are
> > of high maintenance quality. Based on various discussions we drafted an
> > initial policy-like draft, which you can find below. Please comment.
> >
>
> > * In order to assure that packages in third party repositories are
> > being properly maintained, each landing page that offers an apturl
> > link must also contain a prominent link for reporting bugs in the
> > related launchpad project.
> >
>
> At Wine, we would much rather they report bugs straight to our own bug
> tracker, as only I look at the Launchpad bugs. I imagine other projects
> may be the same way.

The requirement to ask for a launchpad bug tracker had two main
goals

1. reduce the work imposed on the review team; having different bug
trackers for different packages could make this harder than necessary

2. allow ubuntu developers to escalate bugs to third party
repository maintainers, without knowing details.

So while its probably a bit cumbersome for 1, I see your concern and
think that having a launchpad project with the (public) bug tracker
details set up should be good enough. Would that work?

>
> > ==== Use-Case Prerequisites ====
> > * Only packages where inclusion in the appropriate Ubuntu repository
> > is not feasible for some technical or licensing reason will be
> > considered.
>
> Do beta packages meet this description?

You cannot really say that without considering individual cases
imo. Some software might be more useful to have in beta form than
others.

Some might even be of higher quality than final versions of other
applications.

>
> >
> > === Repository Quality Requirements ===
> > Users have a right to expect the same level of quality and stability
> > from packages installed via apturl as applications installed from
> > other methods. Therefore, third party repositories for stable Ubuntu
> > release _must_ deliver a stable user-experience comparable to those of
> > ubuntu standards.
> >
>
> Apparently not then. Apparently the goal is for a Wine PPA to take
> over, which is fine I guess now that they're signed. The only thing I
> really lose from all this is that I can no longer collect web statistics
> on package downloads and such -- will Launchpad be providing any such
> feature?

What I think is important here is the stability of the packaging
itself. So if your repository has a good track record to provide
stable packages that have carefully selected package versions and that
don't get refactored frequently, I don't think this should be a
general blocker.

We don't place any restrictions on where you host your
repository. While PPA works (now that its signed) it seems to be ok
to have your own repository as long as its signed et al. What matters
is how that repository is maintained and its track record.

>
> > === Package Requirements ===
> > * Package namespace for the name should start with a unique prefix
> > and not conflict
> > with any existing name on the system
> > * File system layout of the package should be to install to /opt -
> > unless there is a good reason for individual files to be shipped
> > elsewhere.
>
> Some repos will want to replace system packages (eg medibuntu)...this
> seems incompatible with these requirements.


I am not sure what medibuntu does. Is that a derivate?

- Alexander


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-13-2009, 02:38 PM
"Siegfried Gevatter (RainCT)"
 
Default apturl repository whitelist application process

2009/2/12 Alexander Sack <asac@ubuntu.com>:
> * File system layout of the package should be to install to /opt -
> unless there is a good reason for individual files to be shipped
> elsewhere.

What's the reason for this? Perhaps I'm missing something, but I'm
unhappy with having packages messing with my /opt directory; afaik it
has traditionally been a directory for the system owner to place there
what he wants and I don't understand why we want packages to do
anything there now. Further, it may also confuse users who will look
for files in their proper place, and it is inconsistent with all other
packages (including PPAs, etc.) which install files directly into /.

--
Siegfried-Angel Gevatter Pujals (RainCT)
Ubuntu Developer. Debian Contributor.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-13-2009, 02:45 PM
Scott Kitterman
 
Default apturl repository whitelist application process

On Fri, 13 Feb 2009 16:38:57 +0100 "Siegfried Gevatter (RainCT)"
<rainct@ubuntu.com> wrote:
>2009/2/12 Alexander Sack <asac@ubuntu.com>:
>> * File system layout of the package should be to install to /opt -
>> unless there is a good reason for individual files to be shipped
>> elsewhere.
>
>What's the reason for this? Perhaps I'm missing something, but I'm
>unhappy with having packages messing with my /opt directory; afaik it
>has traditionally been a directory for the system owner to place there
>what he wants and I don't understand why we want packages to do
>anything there now. Further, it may also confuse users who will look
>for files in their proper place, and it is inconsistent with all other
>packages (including PPAs, etc.) which install files directly into /.
>

If you look at the packages in Partner, you'll find this is pretty common
for commercial packages. FHS also gives guidance on how to maintain vendor
based namespace separation.

Scott K

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-13-2009, 02:51 PM
"Siegfried Gevatter (RainCT)"
 
Default apturl repository whitelist application process

2009/2/13 Scott Kitterman <ubuntu@kitterman.com>:
> If you look at the packages in Partner, you'll find this is pretty common
> for commercial packages. FHS also gives guidance on how to maintain vendor
> based namespace separation.

Oh okay, I've said nothing then :P.

--
Siegfried-Angel Gevatter Pujals (RainCT)
Ubuntu Developer. Debian Contributor.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-13-2009, 03:15 PM
Michael Vogt
 
Default apturl repository whitelist application process

On Fri, Feb 13, 2009 at 04:38:57PM +0100, Siegfried Gevatter (RainCT) wrote:
> 2009/2/12 Alexander Sack <asac@ubuntu.com>:
> > * File system layout of the package should be to install to /opt -
> > unless there is a good reason for individual files to be shipped
> > elsewhere.
>
> What's the reason for this? Perhaps I'm missing something, but I'm
> unhappy with having packages messing with my /opt directory; afaik it
> has traditionally been a directory for the system owner to place there
> what he wants and I don't understand why we want packages to do
> anything there now. Further, it may also confuse users who will look
> for files in their proper place, and it is inconsistent with all other
> packages (including PPAs, etc.) which install files directly into /.

The rational is that the risk of having conflicts with system package
is minizimed. Having packages install to / would run a higher risk of
undeclated Conclifts that will result in dpkg install
errors. Something we try to avoid this way. Its also quite common for
third party vendors (as ScottK already pointed out).

Cheers,
Michael

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-20-2009, 05:02 PM
Scott Ritchie
 
Default apturl repository whitelist application process

Alexander Sack wrote:
> (resending to list ... forgot to hit the proper reply button )
>
> On Thu, Feb 12, 2009 at 01:35:04PM -0800, Scott Ritchie wrote:
>> Alexander Sack wrote:
>>> Hi all,
>>>
>>> One of the topics on the jaunty agenda was to come up with a process
>>> document that defines how third party repositories can apply for
>>> apturl whitelisting and how we can ensure that such repositories are
>>> of high maintenance quality. Based on various discussions we drafted an
>>> initial policy-like draft, which you can find below. Please comment.
>>>
>>> * In order to assure that packages in third party repositories are
>>> being properly maintained, each landing page that offers an apturl
>>> link must also contain a prominent link for reporting bugs in the
>>> related launchpad project.
>>>
>> At Wine, we would much rather they report bugs straight to our own bug
>> tracker, as only I look at the Launchpad bugs. I imagine other projects
>> may be the same way.
>
> The requirement to ask for a launchpad bug tracker had two main
> goals
>
> 1. reduce the work imposed on the review team; having different bug
> trackers for different packages could make this harder than necessary
>
> 2. allow ubuntu developers to escalate bugs to third party
> repository maintainers, without knowing details.
>
> So while its probably a bit cumbersome for 1, I see your concern and
> think that having a launchpad project with the (public) bug tracker
> details set up should be good enough. Would that work?
>

As long as the actual bug reports end up in our bugzilla we'll be happy.
If we need to install the launchpad bugzilla plugin that would probably
be acceptable as well.

>>> ==== Use-Case Prerequisites ====
>>> * Only packages where inclusion in the appropriate Ubuntu repository
>>> is not feasible for some technical or licensing reason will be
>>> considered.
>> Do beta packages meet this description?
>
> You cannot really say that without considering individual cases
> imo. Some software might be more useful to have in beta form than
> others.
>
> Some might even be of higher quality than final versions of other
> applications.
>

The example I had in mind was where Ubuntu has chosen to keep a stable
package but upstream is offering betas for user testing, which is a
fairly standard third party repository use case. Ubuntu avoids the
possible regressions, but early adopters can still get a reasonable package.

>>> === Repository Quality Requirements ===
>>> Users have a right to expect the same level of quality and stability
>>> from packages installed via apturl as applications installed from
>>> other methods. Therefore, third party repositories for stable Ubuntu
>>> release _must_ deliver a stable user-experience comparable to those of
>>> ubuntu standards.
>>>
>> Apparently not then. Apparently the goal is for a Wine PPA to take
>> over, which is fine I guess now that they're signed. The only thing I
>> really lose from all this is that I can no longer collect web statistics
>> on package downloads and such -- will Launchpad be providing any such
>> feature?
>
> What I think is important here is the stability of the packaging
> itself. So if your repository has a good track record to provide
> stable packages that have carefully selected package versions and that
> don't get refactored frequently, I don't think this should be a
> general blocker.
>
> We don't place any restrictions on where you host your
> repository. While PPA works (now that its signed) it seems to be ok
> to have your own repository as long as its signed et al. What matters
> is how that repository is maintained and its track record.
>

Is there any infrastructure for moving the actual repository? I could
desire to move my repo to a launchpad ppa and it would be nice if we
could push out some sort of update pointing to the new server.

>>> === Package Requirements ===
>>> * Package namespace for the name should start with a unique prefix
>>> and not conflict
>>> with any existing name on the system
>>> * File system layout of the package should be to install to /opt -
>>> unless there is a good reason for individual files to be shipped
>>> elsewhere.
>> Some repos will want to replace system packages (eg medibuntu)...this
>> seems incompatible with these requirements.
>
>
> I am not sure what medibuntu does. Is that a derivate?
>

It's a series of packages designed for people who don't live in caves

https://help.ubuntu.com/community/Medibuntu

What's important here is that they, by necessity, replace some of the
Ubuntu packages. For instance, they provide a replacement version of
mplayer capable of viewing DVDs; requiring them to instead package a
separate version that sat alongside our own stripped mplayer would be
counterproductive.

Thanks,
Scott Ritchie

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

Thread Tools




All times are GMT. The time now is 04:29 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org