Re: git vs dfsg tarballs
- Date: Mon, 19 Nov 2018 18:58:45 +0100
- From: "Enrico Weigelt, metux IT consult" <lkml@xxxxxxxxx>
- Subject: Re: git vs dfsg tarballs
On 19.11.18 17:36, Ian Jackson wrote:
> 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
* 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.
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287