On Mon, 10 Feb 2014 22:13:45 +0100 Wouter Verhelst <wouter@debian.org> wrote: > Sigh. > > On Wed, Feb 05, 2014 at 12:59:23PM +0000, Neil Williams wrote: > > Using packages to support upstream development is a common problem /common problem/common source of problems/ > > and this is exactly where things get awkward. > > No, it is not a *problem*; it is a *method* of doing things. ... one which I've used consistently for more years than I've been a DD and had frequent problems with various assumptions in various tools and in more distributions than just Debian and its derivatives. Hopefully the clarification will show that I'm not questioning the methods of anyone (other than possibly my own). > It is not your place (nor mine) to question another person's methods > of doing things; especially not if said methods are done outside of > Debian, as is here the case. ... and in my ongoing work. If using distribution tools for upstream development was easy, we might not have had people developing tools like pypi, ruby gems, CPAN or a whole range of other non-distribution distributive tools. This isn't just a Debian problem. (Indeed fixing it in Debian isn't going to fix the problems because upstreams will rarely fixate on a single distribution across the entire team - for entirely sane reasons.) It is right for upstream to want to deploy to FHS compliant paths and use dependencies from the main distribution system etc. None of the distribution tools for any of the distributions actually make it easy to then develop within those paths without either rebuilding unreleased upstream packages or copying files into privileged paths. Both of these routes need sudo access which just makes things harder again. Why must every developer have sudo access on the development box? That is exactly why pypi and buildout have got so much traction. It annoys me that I have to use such methods for upstream work because dpkg-dev is too constrained by rules which *only* relate to "official" builds. Doing a quick native build of a non-native package for use and distribution within a known team is a *common requirement* for upstream teams. (e.g. it means that developers can push to a branch, get a quick native package built, uploaded locally, installed via an inotify and available to test without the unnecessary step of building an .orig.tar.gz in the middle.) It's not quite as clean or DRY as restarting a daemon directly from a user-privilege git clone but it is workable. Why should that require two branches of the packaging files? Developing using Debian is not just about development of Debian. Upstream teams use dpkg-dev too. Constraints which are entirely warranted for developing packages destined for ftp-master are directly harmful for developing packages destined for a repository on 192.168. Yes this could work with overrides but those overrides need to be build specific (not package specific or version specific). This is exactly why a ~/.gbp.conf is the right approach. > > Not true. There are options to use debuild or pdebuild or > > dpkg-buildpackage in-place. > > > > e.g. I use: > > > > [DEFAULT] > > #builder = git-pbuilder > > builder = debuild > > cleaner = fakeroot debian/rules clean > > pristine-tar = True > > > > [git-buildpackage] > > export-dir = ../build-area/ > > tarball-dir = ../tarballs/ > > Even if so, this increases the complexity of the system, and requires > people to learn yet another tool to Just Do what was previously > possible with no extra fluff. > > It's okay for a tool (like dpkg) to warn if something doesn't look > right. It's not okay for a tool (like dpkg) to pretend to be smarter > than the person operating said tool. True - however, there will always be a need for tools like git-bp and it is common to use aliases and JDTRT scripts to provide a consistent interface no matter what changes beneath. Thankfully, none of those hacks make it into Debian but that does mean that people within Debian don't get to see how the tools are actually used. Switching a non-native package to native arbitrarily is a necessary use of dpkg and it needs to be supported cleanly and in a way which is easy to override using a per-build configuration option. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: PGP signature