Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
- Date: Tue, 23 May 2017 18:08:02 +0100
- From: Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
Emilio Pozuelo Monfort writes ("Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)"):
> Besides, the sbuild/pbuilder duplicity is the least of your problems
> in terms of multiple workflows, because once you choose one of those
> and set it up, you can build all packages, and don't have to set the
> other one up or learn it.
> Compare that to hacking on a package which may use
> - debhelper, dh, cdbs or no helper at all (!) for debian/rules
> - quilt, dpatch, simple-patchsys, single-debian-patch for patch management
> - format 1.0, 3.0, native, non-native, multiple tarballs... for the source
> - git-buildpackage, git-dpm, other git repo structure with no helper tools,
> svn, bzr, etc for the repository
> - ...
Of these, debhelper/dh/cdbs/raw is difficult to deal with with better
tooling because it's inherint in the source code. However:
* dh $@ is a more automatic way of doing dehelper
* cdbs is on the way out
* no helper at all is definitely on the way out
So at least the last two are a form of technical debt.
> Some of those are easy to learn, and some you don't have to deal
> with if you are doing an NMU (e.g. the repository). It's still a
> pretty complicated picture and a steep learning curve if you want to
> start contributing, or want to join a team that has a completely
> different setup.
> I have to deal with packages in svn, git-bp and plain git, and have
> started to write a set of (ugly) scripts that perform common actions
> in each of those formats, and a generic wrapper that calls the right
> one depending on which repo I'm on, so that I can just do e.g. 'deb
> update; dch; deb commit; deb build; deb release; deb tag' and not
> having to remember all the different command line switches and
> options and so on (I have a bad memory and am lazy). This shouldn't
> be necessary in the first place; at least a bit of homogenization
> would make sense imho.
Part of the problem is that many of the workflows have been pretty
poor: at least, they all have flaws that some people regard as