Proposing a New App Developer Upload Process

[Emmet Hikory]

Daniel Holbach wrote:
> On 04.09.2012 15:28, Emmet Hikory wrote:
> >     The difficulty here is that there is uncontrolled scope for future
> > conflict.  While the Contents.gz file is useful (and the conflictchecker
> > system more so), if both extras and backports are enabled by default, there
> > is no means by which the review board can determine that a given filename
> > will not be provided by a backport of a new package imported from Debian.
> 
> The fairest solution to this problem would be to turn on a
> conflict-check-before-publish for all parts of the archive. This would
> help us find these (and pre-existing) issues immediately and resolve
> them amongst the maintainers and upstreams.

    Completely independently of this discussion, this is a good idea,
although we probably ought have the system respect Breaks, Conflicts,
and Replaces, or we'll end up with lots of false positives.  Mind you,
given the vast number of reports from conflictchecker, it may be that
we would want to put up a review system for some time to clean up the
existing issues prior to actually blocking publication.

    That said, while I agree that such issues can be sorted between the
various developers involved (perhaps easily, perhaps less so (see "node")),
I am much more concerned about the effect on users.  Assume I'm using
Ubuntu Desktop, and I add an extras application to the Dock.  Now assume
there is a namespace conflict for that application, which is resolved by
the extras application taking a new name.  Depending on what I happened 
to install on upgrade (as a new dependency of another installed package),
my Dock entry may behave entirely differently.  More generally, this may
happen for startup programs, so that I would upgrade, reboot, and end up
running something completely unexpected automatically, and I may not even
notice if the automatic execution doesn't load a window, and just believe
my upgrade broke (and potentially end up finding my computer slower, or
behaving oddly, depending on what the new program happened to do).

> The /opt requirement on the other hand unfortunately imposes a huge
> amount of work on 1) app developers because our tools don't work this
> way very easily and 2) Ubuntu maintainers who have to enable path
> lookups in tools which don't know about /opt yet.

    Much of this can be avoided by allowing a common location for extras
files, for example /opt/extras/bin, /opt/extras/applications,
/opt/extras/pixmaps, etc.  If these locations are only permitted to contain
namespace-protected symlinks, then it can be a matter of adding one or two
lines to the 8-12 tools that perform these sorts of discoveries.  No, this
isn't an ideal solution, but it significantly limits the effort required to
support a separate namespace.

    For application developers who prefer standard locations, I don't see
any reason we oughtn't simply add their packages to the repository with
immediate backport: in addition to allowing application developers to put
their files in any policy-compliant location, it automatically provides a
safe upgrade path for users.  Even for software with release cycles that
require significantly more frequent updates than typically provided by our
release cycle, there are few barriers to keeping this updated in backports,
and users who have installed from backports will remain with backports, so
their most active and interested users may be expected to always have the
latest version, while highly conservative users will be able to enjoy a
consistent ABI during the life of a given release (although these users
would need to wait for our next release before using the package).

-- 
Emmet HIKORY