David Planella wrote: > Al 04/09/12 13:06, En/na Scott Kitterman ha escrit: > > I do think the proposal misses a few points though. The purpose of /opt > > was > > not only to limit the access that these apps to the rest of the file > > hierarchy, > > it was also to make sure that files provided by these apps could not be in > > the > > path of Ubuntu packages and to avoid namespace contamination, particularly > > in > > /usr/bin. This proposal addresses neither of those points, so I think it's > > inusufficient as it stands. > > > As per 2. (file system conflicts), we're mentioning: > > "will [...] rely on [...] file path conflict checking on the archive side" > > And I think you're right in that that part needs further development. In > the past, we've discussed a couple of approaches to detect file system > conflicts [2]. They were mainly concerned with scanning the file > contents of packages from different archives, comparing them and > detecting the conflicts. For the scanning part, we've already got an > example on packages.ubuntu.com (reads the Contents.gz file from the > archive and stores the info on a database).
The difficulty here is that there is uncontrolled scope for future conflict. While the Contents.gz file is useful (and the conflictchecker system more so), if both extras and backports are enabled by default, there is no means by which the review board can determine that a given filename will not be provided by a backport of a new package imported from Debian. While it might be possible to change the backport process to exclude such packages, and further require that any extras packages that create such conflict be adjusted for following releases to avoid conflict, this merely masks the confusion: there may be any number of users who have various scripts, desktop files, custom launchers, or other local files that reference a path for which there cannot be any expectation of continuity between releases. All such users may be unable to safely upgrade to the next release without significant local modification: a significant change to the current process where do-release-upgrade is typically a safe operation, especially for those who have verified that any installed extras applications have already become available for the release to which they are upgrading. With the requirement that extras packages only provide files prohibited in Debian policy-compliant packages, while there is potential for conflict in search paths for unadorned filenames (foo.cfg, some-executable, icon.png, etc.), there is no potential for conflict (even future conflict) for full pathnames. Yes, this is exceedingly annoying in terms of providing a seamless interface for extras packages, but the issue can be avoided safely in other ways, by defining a common namespace-protected location into which such packages may store files, and modifying software that uses such things to search multiple locations for things like desktop files, executables, etc. (some of this work has already been discussed in depth, and a smaller portion completed). For those packages that require greater system integration, is there a compelling reason not to provide them as regular packages, with immediate backports? Such new packages in backports should be available to users and provide a future upgrade path. They will also appear in the various systems used to track package coordination between Debian and Ubuntu, and may well be included in Debian directly (or at least considered by those potentially able to introduce a future namespace collision). -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel