On Fri, Oct 02, 2009 at 05:50:02PM +0100, Phil Housley wrote:
How is having a build system perform installs a problem? Basically every build system I know of handles both. Building a software and installing it are two strictly related tasks, and it's only natural to have the same piece of software handle both.Well, running an average make install on Unix sprays data about over 5 or more directories, and leaves you stuck for clearing up, unless you still have the same source checked out and configured the same when you come to uninstall. Not my favourite thing about Unix that, but something package managers have sorted out very neatly.
Yeah, that's one of the reasons why package managers were created in the first place. In fact, I wrote a software small intended to solve this very problem once, but I digress. Of course, the uninstall problem is extremely simple to solve from a build system perspective: just drop the list of installed files somewhere on "make install", and remove everything in that list when "make uninstall" is called. No need to keep the source tree around at all.
Making a Debian package is not a straightforward task: there's a lot of things you need to learn before you can make a simple package, one which contains no shared libraries or similar "complicated" stuff.Maybe I should have chosen a different example, perhaps autopackage or something else more independent than .deb.
I don't know much about autopackage, except for what I've just learned skimming throught the FAQ section of its website, but the fact that it's not capable of resolving package dependencies using the native packages of the distro it's running on top of alone is a deal breaker to my eyes.
Anyway, all I was thinking is that I would like to be able build a package of some sort, which would be independent of the source and build tool. I consider making a package to be part of the build process, and using it not to be.
Making your package autopackage-aware might be a good idea (but read above); however, generating native packages is certainly not, for the reasons I've explained in the previous mail.
Even assuming making a Debian package out of an upstream source tree was trivial, what about people using other distributions, with different package managemen systems? What about people using a *BSD, or Solaris? Would you, as an upstream maintainer, be prepared to define a recipe for every and each of these different package formats? Wouldn't the time spent doing so best used working on the actual code, instead of a dozen or so build systems, each one with its different rules and conventions?Probably not, but in a perfect world the package maintainer could maintain a patch set that dropped their specific files into a new unit in the source tree, and then when they ran $ buildtool package They would get a package made of their own source.
That's pretty much what package maintainers are doing at the moment ;) I mean, if you want to build distro-indipendent packages, you can do it with little effort using autopackage or a similar tool, but you lose many of the advantages native packages bring. On the other hand, if the package maintainer has to drop patches into the source package to obtain a native package, there is little advantage with respect to the current way of doing things, which pretty much consists of obtaining the source package and patching in some way to obtain a native package.
Upstream developers should be able to only care about the code. Distribution-specific issues and quirks are better handled by downstream maintainers.Still, it's all just some ideas at this point.
Of course. I just wanted to give you my opinion, from a point of view you might not have taken into account. -- Andrea Bolognani <eof kiyuko org> Resistance is futile, you will be garbage collected.
Attachment:
signature.asc
Description: Digital signature