Al 05/09/12 14:29, En/na Scott Kitterman ha escrit: > > > David Planella <[email protected]> wrote: > >> Al 05/09/12 05:18, En/na Emmet Hikory ha escrit: >>> Steve Langasek wrote: >>>> On Tue, Sep 04, 2012 at 05:20:47PM -0400, Michael Hall wrote: >>>>>> 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. >>>> >>>> For package renaming that seems easy enough to do, but if we're >> worried >>>> about file conflicts, dynamically prefixing filenames when building >> the >>>> package is going to have an even worse impact on the upstream code >> than >>>> changing directories does. >>> >>> Changing the base filename indeed generates more complicated >> issues, >>> not only in terms of collisions, but also in terms of coordination >> between >>> code and data (e.g. code expects to find ${CONFIG_DIR}/package and >> fails >>> to initialise properly with only ${CONFIG_DIR}/extras-package. >>> >>> However, if we consider "renaming" to apply to the entire path, >> rather >>> than the bare filename, this becomes considerably less of an issue. >> If >>> MyApps were to call tooling that changed the default installation >> location >>> for files while preserving bare filenames, then there is less >> potential >>> for conflict. The standard mechanism for this is to place the >> non-system >>> files in per-package namespaced directories in /opt. >>> >> >> I fully sympathize and understand the advocacy for the use of /opt at >> the packaging level and I would in principle support it: it is the >> standard FHS location for add-on software packages and it creates a >> separate installation namespace that prevents file collisions. In >> theory, it seems the best approach. >> >> However, reality has shown that (a) it is a big hurdle for app >> developers (who are actually the people we're trying to make the >> process >> easier for) to follow this policy and (b) we're enforcing a policy not >> even our tools support. >> >> For (b), what I believe is that it is also clear that no one is going >> to >> work to improve /opt support in tooling or in developer toolkits in the >> near or distant future. So for this alone I consider it to be a dead >> end. >> >> We are assuming that build systems and libraries are flexible enough to >> cater for an alternative installation prefix, and that it will all just >> work at runtime. Unfortunately, this has proven not to be the case. And >> I think the amount of coordination and work that'd be required to >> provide solid /opt support in Ubuntu would be best put in other parts >> of >> the spec, such as its central one: sandboxing. >> >> Just to illustrate the kind of issues we've bumped into in MyApps >> submissions, here's just an example [1]: GtkBuilder does not work with >> the gettext Python library if you specify an alternative location to >> load translations from (e.g. >> '/opt/extras.ubuntu.com/$APP/share/locale/'). So we had to either wait >> or contribute to fix the upstream bug (unlikely as per the complexity >> involved) or implement a workaround. The workaround was to get Quickly >> to modify the source code to use 'locale' instead of 'gettext': an >> effective but nasty solution. >> >> And that's been the journey with /opt so far: continually playing catch >> with the next exception we have to fix or work around. This does not >> sound like a very solid approach or a good experience to provide to app >> developers. And again, I think we should rather direct resources where >> higher priorities lie. >> >> While I like Emmet's idea of delegating the changes required to work >> with /opt to MyApps, this would also mean that the complexity in the >> logic behind the server would greatly increase. And in some cases (e.g. >> hardcoded paths) we would also need to actually modify the sources to >> ensure an app runs. > > I understand it would be a lot of work and people aren't working on it. > What's your basis for believing there will be resources available to > implement this alternate approach? >
We want to make Ubuntu a platform for app developers. This process has a driver, if agreed upon, blueprints will be drafted and discussed at UDS, and resources assigned in the same way we do every cycle. As far as I know, there is no one driving, volunteering or particularly interested in doing the work to better support /opt across our main build systems and runtime or development libraries (and if anyone is, please speak up!). >> Summarizing, I think these are the 3 main points of discussion right >> now: >> >> * Package name conflicts: it seems that we've agreed that a solution >> for >> package name conflicts is to rely on 'extras-' prefixing on the server >> side (i.e. MyApps). This seems to be easy enough to do, fit well with >> other parts of the spec and would be transparent to app developers. > > Agreed. > >> * 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. > At that scale I doubt it's feasible to keep file name uniqueness even among > MyApps packages. I don't see this as it particularly being an issue. If I submit "qreator" and Myapps can tell me that it's already taken, I'll choose "qreator-codes" or any other combination. Same as for domain names or say, Google App Engine app names. > If you want to scale there will have to be some kind of separation in the > file namespace. Using /opt was an attempt at this. BSD Unix separates > system and applications by putting applications in /usr/local. That kind of > approach doesn't really help here. > > Based on the discussion in this thread, I'm now convinced that an environment > where MyApps packages live in their own namespace is absolutely essential to > a scalable process. I'm also almost as convinced that a file system based > separation won't be achieved. > > Fundamentally, I think any successful solution is going to have to place each > package in its own containerized namespace. Anything else is going to > collapse under its own weight if it's successful. > > I think it's better to head down this road now (even if it's harder to do) > than to take the proposed approach and then have to through it out in a year > or two and go down the container route anyway. > We've been using namespace both in the context of package names and files installed by those packages, so I'm not sure I can follow your proposal here. Would you mind adding a couple of examples? Thanks. Cheers, David.
signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
