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.
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.
> > If you insist that it should be
> > testing, could you suggest some name that really uses unstable?
> >
> >> The rationale for testing looks sane,
> >
> > Yes, definitely. We need to build the package against testing if it
> > finally should reach testing.
> >
> >> so I think UNRELEASED should point to testing too.
> >
> > As I said: Please make some suggestion under what "distribution" you
> > like to see metapackages that are faking to target unstable.
>
> I change my mind, so I suggest targeting unstable should use the
> unstable keyword.
I hope that I have given reasons that this is not a good idea.
Other opinions?
> > PS: Thanks also for your other bug report and specifically the patch.
> > I'll upload tomorrow.
>
> Thanks for developing the tools. Making these metapackages was really easy.
Yea, but I'm *really*, *really* happy about enhancement ideas and
patches because I somehow felt a bit "alone" whan working on this and
well in German we say "Kochen im eigenen Saft" which means somehow you
are doing your own stuff a bit disconnected from reality. So your patch
was really welcome and helpful.
Kind regards
Andreas.
[1] https://lists.debian.org/debian-release/2012/06/msg00323.html
[2] https://lists.debian.org/debian-devel-announce/2012/09/msg00005.html
--
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
