Proposing a New App Developer Upload Process

Tue Sep 4 21:20:47 UTC 2012

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

Michael Hall
mhall119 at ubuntu.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCAAGBQJQRnCvAAoJEInUYcGJgfVyWmoP/R5V3ASIAMwH0uZSyxr3A43s
NT7YUFnGnCL45ax4klEUGezEO3iwHanAHlEhgPDyLjiFXLir7AIVpCtF0X8aNHMD
we+14KgJEoq4lAnGzPyx13Enf7UikSSQqXnYVbTl19KG0bxtHhbU9/5r3NO/CtAq
pJS6yTKRZQbmFlhAd5HcgpHD0V/WXJirYdewdShxqYx9A9srptMwtHneTFC3Rxbh
Z+nU3Kj38GA63QQYMYSu0kPgF6vXXOaOuWDuTPxhR40p8Qk+jSpBfBMxw+rvVYFN
/dWJtFKuTwjEDf1BXuzegmBjx2V2jyy1hY1bcFriXai6EwDsj/II3ivwPSFTSMF7
uUeFhYF9rv34GAIWN7NSv80UW6ULsnIYivuIUfRKDgAKkKkYKGAsDhrN+UGOS8a5
9T5Ifmphnpc3aMeRBL63eDFgICm2e+v/lwqep/J906Wy/Ew+49He9iAYGS1h6VkF
C1RIwdcJNQ4v3nYHlFQG4n3w08lYt2508p9goJvYksv2tsD0psxhsR4CDNICkReK
WbTuLsXhP6ssi5P/zrXt7z/HYsZUHv1bRONTeWORjc3wyVjc/w77jcEl/f0NdRos
f22CnoKM8uKLn1ZC+nq1ILmkY9Vx33X4P6I31Cn7S5pmyQxvE4uIX6DtYbNyjyAl
9pfjvlCvlAdq34FK/W9x
=rrLZ
-----END PGP SIGNATURE-----