[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)

On Tue, May 21, 2013 at 2:22 AM, Andreas Tille <tille@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.


Felipe Sateler

Reply to: