Proposing a New App Developer Upload Process

[Scott Kitterman]

On Tuesday, September 04, 2012 10:21:15 AM Michael Hall wrote:
> On 09/04/2012 09:39 AM, Scott Kitterman wrote:
> > The problem isn't just with file conflicts with current packages, it's
> > that
> > these packages will now start using up distro namespace.  If some app
> > developer package ships the file /usr/games/bird-game, even though there's
> > no current conflict, there is a package sync'ed from Debian that also
> > ships /usr/games/bird-game then there's a conflict we have to resolve. 
> > In /opt in a proper vendor namespace this can never happen.
> 
> If bird-game already exists in Extras, and then a different package is
> allowed into backports that will install files into the same location,
> then yes there is a possibility for a conflict.  But I assume part of
> the backports approval process already checks for conflicts, as they may
> exist with another package in the stable release already, so that
> process could easily be extended to include Extras packages as well.

No.  There isn't.  There is a (reasonable) presumption that such issues have 
been resolved in the development release.  I would not be in favor of 
increasing the testing requirements for backports to accommodate external 
repositories.

> > A fairly contrived example derived from the above is if the Debian/Ubuntu
> > package that shipped /usr/games/bird-game was in the archive and an app
> > developer package was uploaded that shipped /usr/bin/bird-game, it could
> > be
> > run instead since /usr/bin precedes /usr/games on the standard user path.
> 
> This would only happen if two different apps were both called
> "bird-game" but otherwise different.  This situation is also possible
> already, even between two packages in Universe.  How is that currently
> handled?

Keep in mind there's no need for package name in the binary name to match, but 
if such a conflict happens, it's an RC bug in Debian terms and one has to be 
renamed.  The Debian bug on /usr/bin/node is an example of how ugly this can 
get.  It's not just enough to check for actual file conflicts though, you have 
to check the entire path to ensure that no files preempt files from other 
packages.  Installing in /opt makes this a non-problem.

> > maybe a Python based app ships an embedded copy of a module since they've
> > tested with that version and don't want to test with the distro version
> > and
> > they write their setup.py to install it in /usr/local/lib/python2.7/dist-
> > packages.  Suddenly every user of that module is now using the app
> > developer package version and not the distro version.
> 
> Installing python modules in the system directories is not allowed under
> this process.  Check the whitelist defined in the "App Preparation"
> section of the spec.

OK.  It seems odd not to allow install in /usr/games.

Scott K