Proposing a New App Developer Upload Process

[Michael Hall]

On 09/04/2012 11:11 AM, Emmet Hikory wrote:
> 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).
> 

We could alternately prevent the importation of packages that conflict
with a package name already in Extras.  That would prevent this from
happening.  We would also have to prevent the importation of packages
that Depends or Recommends on the package we won't be importing.  This
would essentially make package names "first come, first served" between
Extras and Debian.

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

Not only would it require the we carry these patches to system tools and
libraries indefinitely, it would also mean that we encourage developers
to produce apps and packages that are not compatible with our Upstream
(Debian) or any other distro.

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

Sending these packages to Backports instead of Extras doesn't change any
of the potential problems with file and namespace conflicts.

Michael Hall
mhall119 at ubuntu.com