Proposing a New App Developer Upload Process

[Steve Langasek]

Hi Michael,

On Tue, Sep 04, 2012 at 10:50:21AM -0400, 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.

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

> Since Extras package won't be in the development release until
> FeatureFreeze, we can check them against the new packages imported from
> Debian before we forward-copy them from the previous stable release.

That's possible, but has some drawbacks:

 - If Ubuntu chooses to rename the package in universe to address this
   collision, that likely increases the burden on Ubuntu: Debian is unlikely
   to agree to rename a package, or binaries within a package, in response to
   namespace claims from third-party software that's not in the distro.
 - If the package in universe is given precedence, then users may have a
   frustrating experience when upgrading to the new release: either
   update-manager needs to do some complex mapping of extras packages to
   find the new name (if any) of the package, or all extras packages that
   don't exist in the new release need to be removed before upgrading.

In either case, it seems a certain amount of coordination would be required
to provide users a good experience in upgrades, and we quite reasonably want
to avoid the need for that coordination.  The latter option, which seems to
require the least coordination, would also leave users who don't use
update-manager for their updates out in the cold.  And neither option really
addresses the backports issue, where a package may become available in a
devel release that there's user demand for post release, but there's already
a package of the same name (but different origin) in extras.

A namespace would be a good thing because it saves us from having to deal
with these coordination issues.  The /opt namespace hasn't shown itself to
be viable, in part because we don't have tooling that will usefully generate
the binary packages with the correct layout without a lot of fuss, and also
in part because upstream sources seem not to be equipped to handle the split
between /opt and /usr for the points where the package will need to
integrate.

It's possible that namespacing within /usr - for instance, requiring each
subdirectory and binary name to be prefixed with 'extras.' - would give
better results with regards to the upstream build systems, I'm not sure. 
But if we are going to try to do namespacing of extras packages to avoid the
need for coordination, we definitely would need improved package helpers
that support namespacing of packages (i.e., debhelper support).

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20120904/35447340/attachment.pgp>