Hi Felipe,
On Tue, May 28, 2013 at 07:58:12PM -0400, Felipe Sateler wrote:
> > 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.
As far as I know britney has no means to test this (yet). I've got
several bug reports in the past about packages mentioned in Recommends
but not in the archive (any more) - so a new generation of the
metapackages became necessary.
> 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?
Blends-dev is not "silent" - you get a list of affected packages if you
run it. The "downgrade to Suggests" was invented for packages in
contrib and non-free which are also not part of the distribution. The
concept was taken over for any package not in main. (This was rather a
passive "take over" because the actual code did not need any change.) I
somehow have the feeling that I do not fully understand your question -
so if my answer does not fit - please explain the problem more detailed.
> > 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.
And what do you suggest for people trying to create metapackages for say
Ubuntu? They can not write to /usr ...
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
