Proposing a New App Developer Upload Process

[Scott Howard]

On Tue, Sep 4, 2012 at 10:21 AM, Michael Hall <mhall119 at ubuntu.com> 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.

I think people are more concerned with auto-import from Debian than
backports. Debian's approval process knows nothing about Extras, so
there is no mechanism or approval process that checks for conflicts.

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

New Universe packages are pretty much handled by Debian, and while it
is generally avoided there is occasionally a collision (see the
node.js example above in this thread). The problem is that the
proposal is introducing a mechanism for adding packages and files
which our current mechanism (Debian NEW queue) knows nothing about,
greatly increasing the possibility of collision.