Proposing a New App Developer Upload Process

[Scott Kitterman]

On Tuesday, September 04, 2012 11:24:28 AM Michael Hall wrote:
> 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.

Blocking Ubuntu development based on what's in external repositories would be 
an atrocity.  I for one would take the issue to the tech board and ask them no 
to allow such a thing.

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

There is a standard process that people can use to get packages into the 
distribution.  It's not at all surprising that an alternative infrastructure 
would require alternative tools and processes.  I don't understand what's so 
hard about /opt (for any gui application it's the .desktop file that's going to 
drive the applications being started and that can point anywhere).

If the alternative to maintaining some extra processes and tools is to drive a 
namespace wedge between Debian and Ubuntu then I don't think you have a choice 
but to suck up the cost of providing the alternate process/tools if a 
Canonical standard method of delivering third party apps on Ubuntu is what 
Canonical wants to provide.

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

Sure it does.  These packages would have already been in the development 
release and possibly in Debian already where, while there's not an automated, 
formalized process, such issues do get noticed.  I did once suffer from someone 
else inadvertently uploading a package to Debian with a name conflict in 
/usr/bin and it was noticed almost immediately.  By going through the normal 
development process, stuff gets caught.  In the event something gets missed, 
updated backports are trivial to accomplish.

Scott K