Proposing a New App Developer Upload Process

[Didier Roche]

Le 05/09/2012 20:19, Micah Gersten a écrit :
> On 09/05/2012 11:46 AM, Didier Roche wrote:
>> Le 05/09/2012 16:26, David Planella a écrit :
>>> Al 05/09/12 14:29, En/na Scott Kitterman ha escrit:
>>>> David Planella <david.planella at ubuntu.com> wrote:
>>>>
>>>>> * File name conflicts: there I would suggest exploring Daniel's
>>>>> proposal
>>>>> of relying on a conflict checker that works across all archives, so
>>>>> that
>>>>> before an upload is accepted this service checks for any potential
>>>>> clashes and informs the uploader to fix the package before they can do
>>>>> the next submission. The uploader would either be an Ubuntu developer
>>>>> (through the main archive) or an app developer (through extras, via
>>>>> MyApps). This would not only benefit the app developer process, but
>>>>> also
>>>>> fix the existing issue in the regular Ubuntu upload process.
>>>> This would be useful, but insufficient.
>>>>
>>> Could you elaborate on why you think it would be insufficient and what
>>> alternative you believe would be a solution for file name conflicts in
>>> this context?
>>>
>>>>> * Namespace ownership: even with conflict checking there is the issue
>>>>> of
>>>>> who gets to own a particular file name or namespace. E.g. would "Mad
>>>>> Feathered Creatures" (/usr/bin/birds, from Extras) have priority in
>>>>> owning the binary's name if it had been submitted before "Jolly Flying
>>>>> Animals" (also /usr/bin/birds, from Universe)? I think if we want to
>>>>> make apps first-class citizens, even if not part of the distro, a
>>>>> simple
>>>>> suggestion would just be to do it on a first-come-first-serve basis.
>>>> I think it is fundamentally incorrect to give something built on
>>>> Ubuntu namespace priority over Ubuntu itself. Additionally, if this
>>>> service proves popular, this approach would drive a permanent
>>>> namespace wedge between Debian and Ubuntu that might, over time,
>>>> significanly change the nature of the relationship between the two
>>>> distributions.
>>>>
>>> I can see the point of the namespace wedge if we become immensely
>>> popular. What do you think the alternatives are?
>>>
>>>>> What are your thoughts on these?
>>>>>
>>>>> Finally, I believe we do need to provision for those cases, but my
>>>>> understanding is that the potential amount of occurrences would be
>>>>> rather low. So do you think they justify additional Engineering work,
>>>>> or
>>>>> rather they could be dealt manually on a case-by-case basis?
>>>>>
>>>> You've got to consider it now or it won't scale.  IIRC the original
>>>> presentations on this topic at UDS Orlando(?), the intent was to be
>>>> able to scale out to hit numbers of applications equal to or greater
>>>> than the Apple Appstore/Google Play.  If you hit that, then MyApps
>>>> ends up being several times the size of the Ubuntu archive.
>>>>
>>> And that's what we're doing right now. My only concern is not to block
>>> on a situation that will concern just a fraction of the uploads, even at
>>> a higher scale. That's what I'm trying to get a feel for.
>> For all those 3 namespacing/files issues, maybe we can think of a
>> simple solution.
>>
>> I really like Daniel 's idea of a conflict-check-before-publish
>> service. One of the case that was raised on the thread is about "you
>> can't predict the future". What about that example taking back the
>> "Mad feathered creatures" shipping /usr/bin/birds
>> - in precise, only the apps from extras is there
>> - in quantal, we sync from debian, or upload directly to universe
>> "Jolly Flying Animals" which ships the same file (new package or update)
>> -> nothing happens at this stage (remember that extras is not opened)
>> - a little bit (like 3 weeks?) before opening extras, we run (and then
>> continuously run) the conflict-check-before-publish service. This one
>> will detect the new conflict between the two packages, and:
>> 1. add a Conflicts: in "Mad feathered creatures" debian/control file
>> in extras against the package in universe.
>> 2. will send an email to the app developer telling "hey, maybe not all
>> ubuntu user will be able to use your apps as there is this excellent
>> new application <…> into the archive"
>>
>> At the extreme, if the component in conflict is a core component, as
>> the ubuntu archive have an higher priority than the extra one
>> (right?), then the core component will be preferred on dist-upgrade.
>> This has the advantage of:
>> - pushing the burden to the app developer, not to ubuntu developers
>> - avoid having to do conflicts/replaces on our side and so diverging
>> from debian
>> - by pushing the burden to the app developer, still having a automatic
>> update solution integrated into myapps, but mailing them, we ensure to
>> have people committed to their application in ubuntu
>>
>> I think this solution would fit for what will really be and stay,
>> IMHO, a corner case. I doubt with all the precautions taken into the
>> naming and namespace that will happen with every cycles and the few
>> developers in that case will be warned and have time to react before
>> the extras opening. In case they don't react, we have the automatic
>> metadata addition in conflicts: which enables apt to deal with it.
>>
> Worrying about extras when extras opens for the release is not
> sufficient.  People upgrading in the mean time will have file conflicts
> between packages.  Also, once you have the file conflict, regardless of
> what you do in the new extras release, you still have to deal with the
> file conflict in the archive and/or in the old extras release as dpkg
> installs are nondeterministic.
Before extras will be opened before the next release version, so for 
normal/non techy user, there is no issue. People who upgrade an existing 
system to the development release mostly uses . Real persons  upgrading 
to the next release, at least in the french community, uses our 
recommended tool for upgrading to next release: do-release-upgrade and 
the gui equivalent which propose to remove "obsolete packages" (as 
extras package will be marked that way as there is no repository 
proposing them before extras opens). We can change that logic and 
warning that we remove all package with extra-* as we agreed on the 
thread to have a different package naming convention.
And again, this is really of subset of the +1 testers, most of them uses 
virtualbox, or in a separate partition, they don't use their normal 
system for that. For the remaining using their normal system, upgrading 
before extras opens for +1 (which should be around beta), and don't use 
our supported tool for upgrading and only apt. I think they are 
technical enough to deal with the unmarked conflict.

> Having said that, I think that these apps should all be in their own
> namespace and/or container such that they cannot impact anything in the
> main archive.

Can you detail a little bit more? did you read the previous thread 
content about issues of the past experiment of this? Do you have any 
solution to propose rather than just bringing a hard requirement without 
any proposal?

Didier