Re: change proposal for handling of Depends: field in task files
Hi Ole,
On Sat, Aug 05, 2017 at 02:04:08PM +0200, Ole Streicher wrote:
> I my feeling right that you basically propose the same as I?
The idea is the same - I'd like to go simpler without the technical
format definition stuff.
> So, we should do a 0th step and fix blends-dev to accept Recommends: as
> well (and translates it to Recommends: at package dependency level)
Yes.
> > I think the first change in blends-dev should be to accept Recommends.
>
> Ack. Should be trivial to fix.
I'm pretty sure that it would be easy enough that even I could do it but
I'd be more than happy if some Perl programmer would take over.
> > I admit for the sake of simplicity (and the fact that we have only a
> > few Blends we could deal with easily) we could simply fix blends-dev
> > to accept Recommends.
>
> Ack. This is the first step and seems not nontroversial at all.
Yes. It could be implemented right now.
> > After this we could inform those few Blends maintainers (I'll be
> > responsible for med, science and junior)
>
> Ack. The usual way to "inform other blends" (which means: ask them to
> change something in their blends packages) is a bug report, which would
> also help us to track the progress.
Yes, bug reports should be fine. I'll convert the Blends where I'm
responsible before to use them as test case.
> > I guess Debian GIS and Debian Games are also happy about the change,
> > no idea about Debian Multimedia and how/whether it is maintained at
> > all, Debian Accessibilities only uses web sentinel (no metapackages -
> > I would do the change here as well) and finally EzGo which is kind of
> > a riddle to me.
>
> Non maintained blends cout get an NMU, and also then the bug report
> helps documenting the process.
Definitely.
> > In a second round we could later change the behaviour of Depends.
>
> Ack. And to make sure that no older blends metapackage slips through
> (maybe local, or in a derivative), we should mark the new format
> somehow -- which brings the "Format:" header line into the game.
>
> Any old-style blends metapackage would then fail to build (and could
> again easily be fixed).
As I tried to express I'm relaxed about the Format header since to my
personal opinion the effort-benefit releation is not very positive.
I'm perfectly fine if somebody wants to implements and will test it.
> > I agree that technically that's a weak solution but should work if
> > somebody intends to reproduce older packages since we would fail to
> > reproduce older packages from older Git commits. However, I do not
> > consider this a strong argument over burning developer time with
> > implementing and testing a more complex versioning + format system.
>
> I do not see a use case for this. Even when backported, one could still
> generate the source package on a current system. And if we provide a
> simple (sed) script that does s/^Depends:/Recommends:/ (and adds the
> format line in the begining), one could manually apply this before
> further processing with blends-dev.
As I said that's perfectly fine for me. May be I failed to express
correctly what I meant: The only flaw I would see in skipping the
explicite mentioning of Format at all would be that you can not recreate
old metapackages. Since I fully agree that there is no real use case
for this I would take the "risk" and do not deal with the Format hassle
(for the current problem).
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: