Proposing a New App Developer Upload Process

Emmet Hikory persia at ubuntu.com
Tue Sep 4 17:02:11 UTC 2012


Michael Hall wrote:
> 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.

    Package names are relatively easy: there aren't that many of them,
and they can be namespaced without significant impact.  My concern is
about filenames.

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

    We rather ought encourage developers to use build systems that allow
one to specify an install location: then the difference between installing
to /opt/ and system locations becomes entirely a matter of a preference in
the packaging: other format distributions will not even notice.  Distributions
that use Debian-format packages are likely to be downstream from either Debian
or Ubuntu: if we share the optional /opt/ packaging preference with Debian,
then it is trivial for any distribution to adopt the package as either extra
or part of the system with very little effort.

    As for patches in system tools, at least for icon cache, path, and desktop
file discovery, this is one or two lines in a configuration file that already
carries Ubuntu-specific patches.  Is there a specific example of a discovery
mechanism that is more complicated to change?

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

    I don't care what the repository is called.  My understanding of the
backports process is that it requires the package *also* be present in the
following release, as a regular system package.  As such, it is automatically
tracked by existing tools in Debian and likely to cause discussion in the
event that someone wants to generate package name or filename conflicts.

    Conversely, my understanding of the extras process is that there is no
expectation as to whether the package will be available for the following
release or not, and that it uses a separate repository not currently tracked
by any of the existing tools in Debian.  As a result, there are significant
chances that either 1) a conflict is introduced by some package in Debian,
or 2) an extras maintainer may significantly delay adding a package to extras
(perhaps until after release) as a result of conflict resolution discussions,
which may adversely impact end users.

    The above notwithstanding, I'm all in favour of being able to safely add
new or frequently changing packages with policy-compliant filenames to Ubuntu,
both during the life of a release and as part of future releases.  I'm just
concerned that our attempts to work around some of the problems we have had
with such systems in the past may lead to us creating new systems that closely
parallel older systems without addressing the issues that caused the prior
systems to no longer be considered ideal for future progress.  Given my
experience with cleanup after the pull of all the random apt repos, and work
with REVU, I feel fairly strongly that we ought create an implementation that
closely integrates with exsting Debian tools and avoids as many potential
sources of conflict as possible.  If we are to have a high-throughput mostly
automated mechanism for new packages to be added, we need to be sure that we
have not created too many bottlenecks relying on human discussion, whether
this be too high a reviewer overhead, a need to coordinate yet another
namespace conflict resolution forum, or anything else.

    Based on this belief, while we might have any arbitrary process by which
applications are submitted for review, the only reason I can see for treating
the packages as any different than any other unseeded package is either some
technical limitation or if we somehow felt that we had different levels of
trust for packages in one place or another (as reflected by our trust in the
reviewers, presumably).  The more effort we spend to create a "special" and
"different" class of applications, the greater the chance we have created
a division in the self-perceived identities of our various developers where
none need exist.

    Of course, this may not be considered safe (see all the sandboxing
discussion in the spec), but I believe we'd do better to help those who
are developing applications follow a model that generates software that
we would be happy to welcome as regular system software than to encourage
those who might need greater system access to find ways to work around
whatever limitations we might attempt to put in place.  If we can use
the same front-end to the application developers for *both* types of
applications, we reduce both confusion and dissention, and likely find
that our implementation need have fewer loopholes, as there is a means
to easily move software from the restricted facility to a more regular
facility, with full filesytem access, no network restrictions, etc.
which we may use whenever we find a package that might otherwise require
an extension to the facilities available.

-- 
Emmet HIKORY



More information about the ubuntu-devel mailing list