Proposing a New App Developer Upload Process

[Scott Kitterman]

Michael Hall <mhall119 at ubuntu.com> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>
>On 09/04/2012 04:41 PM, Steve Langasek wrote:
>> Hi Michael,
>> 
>> On Tue, Sep 04, 2012 at 10:50:21AM -0400, Michael Hall wrote:
>>>>> On 09/04/2012 09:39 AM, Scott Kitterman wrote:
>>>>>> The problem isn't just with file conflicts with current
>>>>>> packages, it's that these packages will now start using up
>>>>>> distro namespace.  If some app developer package ships the
>>>>>> file /usr/games/bird-game, even though there's no current
>>>>>> conflict, there is a package sync'ed from Debian that also
>>>>>> ships /usr/games/bird-game then there's a conflict we have
>>>>>> to resolve.  In /opt in a proper vendor namespace this can
>>>>>> never happen.
>> 
>>>>> If bird-game already exists in Extras, and then a different
>>>>> package is allowed into backports that will install files
>>>>> into the same location, then yes there is a possibility for a
>>>>> conflict.  But I assume part of the backports approval
>>>>> process already checks for conflicts, as they may exist with
>>>>> another package in the stable release already, so that 
>>>>> process could easily be extended to include Extras packages
>>>>> as well.
>> 
>>>> I think people are more concerned with auto-import from Debian
>>>> than backports. Debian's approval process knows nothing about
>>>> Extras, so there is no mechanism or approval process that
>>>> checks for conflicts.
>> 
>>> Since Extras package won't be in the development release until 
>>> FeatureFreeze, we can check them against the new packages
>>> imported from Debian before we forward-copy them from the
>>> previous stable release.
>> 
>> That's possible, but has some drawbacks:
>> 
>> - If Ubuntu chooses to rename the package in universe to address
>> this collision, that likely increases the burden on Ubuntu: Debian
>> is unlikely to agree to rename a package, or binaries within a
>> package, in response to namespace claims from third-party software
>> that's not in the distro. - If the package in universe is given
>> precedence, then users may have a frustrating experience when
>> upgrading to the new release: either update-manager needs to do
>> some complex mapping of extras packages to find the new name (if
>> any) of the package, or all extras packages that don't exist in the
>> new release need to be removed before upgrading.
>> 
>> In either case, it seems a certain amount of coordination would be
>> required to provide users a good experience in upgrades, and we
>> quite reasonably want to avoid the need for that coordination.  The
>> latter option, which seems to require the least coordination, would
>> also leave users who don't use update-manager for their updates out
>> in the cold.  And neither option really addresses the backports
>> issue, where a package may become available in a devel release that
>> there's user demand for post release, but there's already a package
>> of the same name (but different origin) in extras.
>> 
>> A namespace would be a good thing because it saves us from having
>> to deal with these coordination issues.  The /opt namespace hasn't
>> shown itself to be viable, in part because we don't have tooling
>> that will usefully generate the binary packages with the correct
>> layout without a lot of fuss, and also in part because upstream
>> sources seem not to be equipped to handle the split between /opt
>> and /usr for the points where the package will need to integrate.
>> 
>> It's possible that namespacing within /usr - for instance,
>> requiring each subdirectory and binary name to be prefixed with
>> 'extras.' - would give better results with regards to the upstream
>> build systems, I'm not sure. But if we are going to try to do
>> namespacing of extras packages to avoid the need for coordination,
>> we definitely would need improved package helpers that support
>> namespacing of packages (i.e., debhelper support).
>> 
>> 
>> 
>
>Would it be reasonable for MyApps to add a package name prefix to the
>submitted package, rather than requiring the developer to do so?
>MyApps will already be modifying the submitted package to include the
>generator AppArmor profile.
>
>So, for example, if I submit quickly-gtk as a source package to
>MyApps, it would convert it to extras-quickly-gtk, add the AppArmor
>profile, and re-build the source package before submitting it to the
>PPA/buildds.

I think that's the right direction to be looking in, both for package names and files in the system path.

Scott K