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

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@metux.net -- +49-151-27565287

Reply to: