On Sun, 2012-09-09 at 03:11 +0200, Guillem Jover wrote: > Hi! Hey Guillem. > This is not really supported (or at least not generally tested), and > there's probably a ton of software with the assumption that the > directory and companion files are located in the topdir of the > source tree. That's what I figured. > You still might (?) be able to concoct a command-line invokation to > dpkg-buildpackage that passes enough information to the inferior dpkg > tools so that the packaging can be relocated. Stuff like -R for > dpkg-buildpackage; -c, -l, -T, -f for dpkg-genchanges via > --changes-option, etc, etc. I don't think debhelper might be happy > with the new path though. > > But then it might be just easier to install the packaging files into > the expected place at source distribution time («make dist» in > autotools parlance) through a “dist hook” for example. Yes, I think that could work. The only problem is that I still couldn't run dpkg-buildpackage from the root on its own. > I realize the rpm spec files might seem like being advantageous on > this, but then it's usually not recommended to have packaging on the > upstream tree, Yes, I'm familiar with this line of thinking. My project has a few unique considerations that make maintaining its packages upstream convenient both for its maintainers and its users though. > and an even “easier” way might be to just stick the > packaging in its own branch on the source repository, which would > then not clutter your normal project tree. As in in a separate repository? That could work too. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com
Attachment:
signature.asc
Description: This is a digitally signed message part