Hi Andreas,

I my feeling right that you basically propose the same as I?

Andreas Tille <andr...@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


Reply via email to