[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Metapackages targeting at testing pool or not (Was: Bug#709058: blends-dev: UNRELEASED and unstable sources.list differ)

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



Reply to: