Re: change proposal for handling of Depends: field in task files
Hi Andreas,
I my feeling right that you basically propose the same as I?
Andreas Tille <andreas@an3as.eu> writes:
> I'm all for it. I just did `sed -i 's/^Depends/Recommends/' tasks/*` in
> Debian Med packages but while I assumed that this would work with
> blends-dev unfortunately it does not. I need to check this later since
> I'm busy with other stuff. I think the web sentinel threats Depends and
> Recommends equally so the replacement should not harm.
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)
>> and then change the behaviour of the "blends-dev" package.
>
> I think the first change in blends-dev should be to accept Recommends.
Ack. Should be trivial to fix.
> 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.
> 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.
> 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.
> 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).
> 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.
Best regards
Ole
Reply to: