Daniel Holbach wrote: > On 04.09.2012 15:28, Emmet Hikory wrote: > > 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. > > The fairest solution to this problem would be to turn on a > conflict-check-before-publish for all parts of the archive. This would > help us find these (and pre-existing) issues immediately and resolve > them amongst the maintainers and upstreams.
Completely independently of this discussion, this is a good idea, although we probably ought have the system respect Breaks, Conflicts, and Replaces, or we'll end up with lots of false positives. Mind you, given the vast number of reports from conflictchecker, it may be that we would want to put up a review system for some time to clean up the existing issues prior to actually blocking publication. That said, while I agree that such issues can be sorted between the various developers involved (perhaps easily, perhaps less so (see "node")), I am much more concerned about the effect on users. Assume I'm using Ubuntu Desktop, and I add an extras application to the Dock. Now assume there is a namespace conflict for that application, which is resolved by the extras application taking a new name. Depending on what I happened to install on upgrade (as a new dependency of another installed package), my Dock entry may behave entirely differently. More generally, this may happen for startup programs, so that I would upgrade, reboot, and end up running something completely unexpected automatically, and I may not even notice if the automatic execution doesn't load a window, and just believe my upgrade broke (and potentially end up finding my computer slower, or behaving oddly, depending on what the new program happened to do). > 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. 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). -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel