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.
--
Saludos,
Felipe Sateler
Reply to: