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
