Re: [Vala] Building a build tool



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



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