Michael Hall <[email protected]> wrote:
>-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > > >On 09/04/2012 04:41 PM, Steve Langasek wrote: >> Hi Michael, >> >> On Tue, Sep 04, 2012 at 10:50:21AM -0400, Michael Hall wrote: >>>>> On 09/04/2012 09:39 AM, Scott Kitterman wrote: >>>>>> The problem isn't just with file conflicts with current >>>>>> packages, it's that these packages will now start using up >>>>>> distro namespace. If some app developer package ships the >>>>>> file /usr/games/bird-game, even though there's no current >>>>>> conflict, there is a package sync'ed from Debian that also >>>>>> ships /usr/games/bird-game then there's a conflict we have >>>>>> to resolve. In /opt in a proper vendor namespace this can >>>>>> never happen. >> >>>>> If bird-game already exists in Extras, and then a different >>>>> package is allowed into backports that will install files >>>>> into the same location, then yes there is a possibility for a >>>>> conflict. But I assume part of the backports approval >>>>> process already checks for conflicts, as they may exist with >>>>> another package in the stable release already, so that >>>>> process could easily be extended to include Extras packages >>>>> as well. >> >>>> I think people are more concerned with auto-import from Debian >>>> than backports. Debian's approval process knows nothing about >>>> Extras, so there is no mechanism or approval process that >>>> checks for conflicts. >> >>> Since Extras package won't be in the development release until >>> FeatureFreeze, we can check them against the new packages >>> imported from Debian before we forward-copy them from the >>> previous stable release. >> >> That's possible, but has some drawbacks: >> >> - If Ubuntu chooses to rename the package in universe to address >> this collision, that likely increases the burden on Ubuntu: Debian >> is unlikely to agree to rename a package, or binaries within a >> package, in response to namespace claims from third-party software >> that's not in the distro. - If the package in universe is given >> precedence, then users may have a frustrating experience when >> upgrading to the new release: either update-manager needs to do >> some complex mapping of extras packages to find the new name (if >> any) of the package, or all extras packages that don't exist in the >> new release need to be removed before upgrading. >> >> In either case, it seems a certain amount of coordination would be >> required to provide users a good experience in upgrades, and we >> quite reasonably want to avoid the need for that coordination. The >> latter option, which seems to require the least coordination, would >> also leave users who don't use update-manager for their updates out >> in the cold. And neither option really addresses the backports >> issue, where a package may become available in a devel release that >> there's user demand for post release, but there's already a package >> of the same name (but different origin) in extras. >> >> A namespace would be a good thing because it saves us from having >> to deal with these coordination issues. The /opt namespace hasn't >> shown itself to be viable, in part because we don't have tooling >> that will usefully generate the binary packages with the correct >> layout without a lot of fuss, and also in part because upstream >> sources seem not to be equipped to handle the split between /opt >> and /usr for the points where the package will need to integrate. >> >> 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. I think that's the right direction to be looking in, both for package names and files in the system path. Scott K -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
