Michael Hall wrote: > We could alternately prevent the importation of packages that conflict > with a package name already in Extras. That would prevent this from > happening. We would also have to prevent the importation of packages > that Depends or Recommends on the package we won't be importing. This > would essentially make package names "first come, first served" between > Extras and Debian.
Package names are relatively easy: there aren't that many of them, and they can be namespaced without significant impact. My concern is about filenames. > >> The /opt requirement on the other hand unfortunately imposes a huge > >> amount of work on 1) app developers because our tools don't work this > >> way very easily and 2) Ubuntu maintainers who have to enable path > >> lookups in tools which don't know about /opt yet. > > > > Much of this can be avoided by allowing a common location for extras > > files, for example /opt/extras/bin, /opt/extras/applications, > > /opt/extras/pixmaps, etc. If these locations are only permitted to contain > > namespace-protected symlinks, then it can be a matter of adding one or two > > lines to the 8-12 tools that perform these sorts of discoveries. No, this > > isn't an ideal solution, but it significantly limits the effort required to > > support a separate namespace. > > > > Not only would it require the we carry these patches to system tools and > libraries indefinitely, it would also mean that we encourage developers > to produce apps and packages that are not compatible with our Upstream > (Debian) or any other distro. We rather ought encourage developers to use build systems that allow one to specify an install location: then the difference between installing to /opt/ and system locations becomes entirely a matter of a preference in the packaging: other format distributions will not even notice. Distributions that use Debian-format packages are likely to be downstream from either Debian or Ubuntu: if we share the optional /opt/ packaging preference with Debian, then it is trivial for any distribution to adopt the package as either extra or part of the system with very little effort. As for patches in system tools, at least for icon cache, path, and desktop file discovery, this is one or two lines in a configuration file that already carries Ubuntu-specific patches. Is there a specific example of a discovery mechanism that is more complicated to change? > > For application developers who prefer standard locations, I don't see > > any reason we oughtn't simply add their packages to the repository with > > immediate backport: in addition to allowing application developers to put > > their files in any policy-compliant location, it automatically provides a > > safe upgrade path for users. Even for software with release cycles that > > require significantly more frequent updates than typically provided by our > > release cycle, there are few barriers to keeping this updated in backports, > > and users who have installed from backports will remain with backports, so > > their most active and interested users may be expected to always have the > > latest version, while highly conservative users will be able to enjoy a > > consistent ABI during the life of a given release (although these users > > would need to wait for our next release before using the package). > > > > Sending these packages to Backports instead of Extras doesn't change any > of the potential problems with file and namespace conflicts. I don't care what the repository is called. My understanding of the backports process is that it requires the package *also* be present in the following release, as a regular system package. As such, it is automatically tracked by existing tools in Debian and likely to cause discussion in the event that someone wants to generate package name or filename conflicts. Conversely, my understanding of the extras process is that there is no expectation as to whether the package will be available for the following release or not, and that it uses a separate repository not currently tracked by any of the existing tools in Debian. As a result, there are significant chances that either 1) a conflict is introduced by some package in Debian, or 2) an extras maintainer may significantly delay adding a package to extras (perhaps until after release) as a result of conflict resolution discussions, which may adversely impact end users. The above notwithstanding, I'm all in favour of being able to safely add new or frequently changing packages with policy-compliant filenames to Ubuntu, both during the life of a release and as part of future releases. I'm just concerned that our attempts to work around some of the problems we have had with such systems in the past may lead to us creating new systems that closely parallel older systems without addressing the issues that caused the prior systems to no longer be considered ideal for future progress. Given my experience with cleanup after the pull of all the random apt repos, and work with REVU, I feel fairly strongly that we ought create an implementation that closely integrates with exsting Debian tools and avoids as many potential sources of conflict as possible. If we are to have a high-throughput mostly automated mechanism for new packages to be added, we need to be sure that we have not created too many bottlenecks relying on human discussion, whether this be too high a reviewer overhead, a need to coordinate yet another namespace conflict resolution forum, or anything else. Based on this belief, while we might have any arbitrary process by which applications are submitted for review, the only reason I can see for treating the packages as any different than any other unseeded package is either some technical limitation or if we somehow felt that we had different levels of trust for packages in one place or another (as reflected by our trust in the reviewers, presumably). The more effort we spend to create a "special" and "different" class of applications, the greater the chance we have created a division in the self-perceived identities of our various developers where none need exist. Of course, this may not be considered safe (see all the sandboxing discussion in the spec), but I believe we'd do better to help those who are developing applications follow a model that generates software that we would be happy to welcome as regular system software than to encourage those who might need greater system access to find ways to work around whatever limitations we might attempt to put in place. If we can use the same front-end to the application developers for *both* types of applications, we reduce both confusion and dissention, and likely find that our implementation need have fewer loopholes, as there is a means to easily move software from the restricted facility to a more regular facility, with full filesytem access, no network restrictions, etc. which we may use whenever we find a package that might otherwise require an extension to the facilities available. -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel