On 19.11.18 17:36, Ian Jackson wrote: Hi,
> I am saying that for packages whose Debian maintainer follow those> > recommendations, much of what you want would be straightforward - or,> anyway a lot easier. So I was plugging my recommendations. Unfortunately, those packages I'm coping w/ don't really follow that. Kodi is an really unpleasant example: * unclear orig<->dfsg relationship (I'll have to analyze them one by one and adapt my import scripts) * very non-linear history (eg. new upstream trees, sometimes even completely unrelated branches, directly merged down into the deb branch) * lot's of patches against non-existing files * rules trying to touch missing source files/directories. >> Here're some examples on how my deb branches look like:> > Not sure what you >> mean by `your deb branches', Those who add the debian/* stuff, and possibly other patches. In my model, they're always linear descendants of the corresponding upstream release tag. > but looking at what> Debian gives you:> >> * canonical ref names> > dgit > (dgit clone, dgit fetch) will give you this, regardless of the> maintainer's behaviour. hmm, looks like good start. But it doesn't really look easy to clone from different distros and specific or yet unreleased versions. and one of my main problems remains unresolved: linear history ontop of the upstream's release tag. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287