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