Proposing a New App Developer Upload Process

[Emmet Hikory]

David Planella wrote:
> Al 04/09/12 13:06, En/na Scott Kitterman ha escrit:
> > I do think the proposal misses a few points though.  The purpose of /opt was 
> > not only to limit the access that these apps to the rest of the file hierarchy, 
> > it was also to make sure that files provided by these apps could not be in the 
> > path of Ubuntu packages and to avoid namespace contamination, particularly in 
> > /usr/bin.  This proposal addresses neither of those points, so I think it's 
> > inusufficient as it stands.
> > 
> As per 2. (file system conflicts), we're mentioning:
> 
> "will [...] rely on [...] file path conflict checking on the archive side"
> 
> And I think you're right in that that part needs further development. In
> the past, we've discussed a couple of approaches to detect file system
> conflicts [2]. They were mainly concerned with scanning the file
> contents of packages from different archives, comparing them and
> detecting the conflicts. For the scanning part, we've already got an
> example on packages.ubuntu.com (reads the Contents.gz file from the
> archive and stores the info on a database).

    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.

    While it might be possible to change the backport process to exclude
such packages, and further require that any extras packages that create
such conflict be adjusted for following releases to avoid conflict, this
merely masks the confusion: there may be any number of users who have
various scripts, desktop files, custom launchers, or other local files
that reference a path for which there cannot be any expectation of
continuity between releases.  All such users may be unable to safely upgrade
to the next release without significant local modification: a significant
change to the current process where do-release-upgrade is typically a safe
operation, especially for those who have verified that any installed extras
applications have already become available for the release to which they are
upgrading.

    With the requirement that extras packages only provide files prohibited
in Debian policy-compliant packages, while there is potential for conflict in
search paths for unadorned filenames (foo.cfg, some-executable, icon.png,
etc.), there is no potential for conflict (even future conflict) for full
pathnames.

    Yes, this is exceedingly annoying in terms of providing a seamless
interface for extras packages, but the issue can be avoided safely in other
ways, by defining a common namespace-protected location into which such
packages may store files, and modifying software that uses such things to
search multiple locations for things like desktop files, executables, etc.
(some of this work has already been discussed in depth, and a smaller
portion completed).

    For those packages that require greater system integration, is there a
compelling reason not to provide them as regular packages, with immediate
backports?  Such new packages in backports should be available to users and
provide a future upgrade path.  They will also appear in the various systems
used to track package coordination between Debian and Ubuntu, and may well be
included in Debian directly (or at least considered by those potentially able
to introduce a future namespace collision).

-- 
Emmet HIKORY