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

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.

Right!

> 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.

Yes.

> 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
important.

Ian.


Reply to: