On Tue, May 21, 2013 at 2:22 AM, Andreas Tille <ti...@debian.org> wrote: > Hi, > > [I'm taking this bug report to the mailing list because I would like to > see a wider opinion.] > > On Mon, May 20, 2013 at 06:30:58PM -0400, Felipe Sateler wrote: >> > On Mon, May 20, 2013 at 10:20:57AM -0400, Felipe Sateler wrote: >> >> >> >> sources.list.unstable points to testing, but s.l.UNRELEASED points to >> >> unstable. >> > >> > I confirm that it might be a bit unusual to use something else for >> > UNRELEASED than if you do the final upload to unstable. However, there >> > was some request for having one sources.list.xxx that also points to >> > unstable. Do you think this is a real constraint? >> >> I think I take back my comment about the rationale for testing, >> because I've just realized that metapackages use recommends by >> default, so they can't be entangled in any transition. >> >> So I guess I changed my mind to s.l.unstable should point to unstable. > > I try to give a hopefully convincing example that if you build > metapackages for unstable the packages residing in testing should be > verified. Assume we are in freeze time (I guess everybody can perfectly > remember thise times. ;-)) It makes perfectly sense to upload the > metapackages *in* freeze time and *not* *before* (I regularly warn > release team about this[1] - this is necessary because the members of > the team might change from release to release and are not comfortable > with this procedure). The rationale is that in freeze time packages > could vanish from testing and it only makes sense to create the > metapackages if you are really sure that no RC bug against any of your > target packages might remain. You can see from the unblock requests for > the Wheezy release how late in this process I did this (#696387, > #705609, #705046, #702722). > > Your argument taht war are using "only" recommends is wrong because also > recommends need to be fullfilled inside the release. Only suggested > packages do not need to exist. So I insist that s.l.unstable needs to > point to testing to enable propagation of the metapackages to testing.
AFAIK, britney doesn't enforce this. However, it is a valid point, metapackages should not Recommend non-existing packages. But I would counterargue that the tasks descriptions should not Depend on packages that will not be part of the release, just as regular packages do. In other words, maybe blends-dev should abort on missing packages instead of just listing them out. In other words, why silently omit packages that don't exist in the target distribution? > > The rationale why we are using Recommends instead of Depends is not that > we try to be safe against missing packages but rather to enable the user > to be able to deinstall a certain package (for whatever reason) without > loosing the metapackage. This was discussed ages ago (before the stuff > even was called Blends, I'm to lazy to seek for the links). The same > problem occures with non-Blends metapackages. You might remember the > longish thread about network manager that should not be mentioned as > Depends in the Gnome metapackages. I have not read the whole flame but > if I remember correctly the CTTE finally needed to overruled the > maintainers[2] to use Recommends ... > > So IMHO this issue is quite clear. > >> > Finally it is a >> > config file you can change if needed. >> >> I'd rather not. I find it weird that build configuration can live >> outside the package being built. > > That's (partly) correct. You are creating the source of the metapackage > outside of the package build process. Historically everything was > merged in one process but this was luckily dropped because otherwise you > were not able to build on a standalone machine. (Holger has filed a bug > report about this and I think I changed this in cdd-0.5.0.) So you are > building the source tarball on any "local" machine and typically not in > a chroot like pbuilder. Theoretically you could even do manual changes > afterwards which is not recommended for sure but it would at least not > break the process in principle. > > However, it is not recommended to stretch this configuration thing to > far. The main point for the target distribution feature is rather not > do dirty tricks with testing-unstable changes. It is intended for > derivatives to simply drop their own sources.list in /etc/blends and > can perfectly work with the toolset without changing anything. I think /usr/share/blends-dev/sources.lists.d/ would be a better place, then. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
