[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: change proposal for handling of Depends: field in task files



Hi,

besides Petters experiences with Depends there a several discussions on
debian-devel list giving good reasons that metapackages should feature
Recommends instead of Depends.  I agree that in *some* *exceptions*
having Depends might be a feature you really want.

On Sat, Aug 05, 2017 at 11:22:25AM +0200, Ole Streicher wrote:
> 
> The problem here is IMO that the task still says "Depends", which is
> translated into "Recommends": this is just not intuitive.

ACK.

> And it
> requires that a task that has a strong real "Depends" needs to do some
> workarounds.

I admit that is a nuisance.
 
> The number of blends is countable: I personally like the idea to first
> replace all "Depends" with "Recommends" in all tasks files,

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.

> and then
> change the behaviour of the "blends-dev" package.

I think the first change in blends-dev should be to accept Recommends.
 
> We should also introduce a format identifier to make future changes
> easier; so my proposal would be:
> 
> 1. We write a (maybe preliminary) format description and publish it
> under a well-defined URL
> 
> 2. We create bugs for all known build-dependencies of blends-dev to
> 2.1 'sed s/^Depends:/Recommends:/ -i tasks/*`
> 2.2 insert a "Format: https://blends.d.o/format"; as first line to
>     indicate that the new format is used
> 
> 3. Once all switched (should be not that difficult, due to the
>  straightforward change), we upload a new version of blends-dev that
>  checks the format id and
>  a) either exits with error if it is not there or a wrong one
>  b) prints a depretation warning and proceeds with the old style in that
>     case
>  Because of the trivial change, I would prefer a).

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.  After this we could inform those few Blends
maintainers (I'll be responsible for med, science and junior), 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.
 
In a second round we could later change the behaviour of Depends.  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.

Kind regards

       Andreas.

-- 
http://fam-tille.de


Reply to: