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 <[email protected]> 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
--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
