Re: [Vala] Building a build tool



2009/10/2 Andrea Bolognani <eof kiyuko org>:
On Fri, Oct 02, 2009 at 01:30:58PM +0100, Phil Housley wrote:

With my Debian package maintainer hat on, I kindly ask you _not_ to do that.

Upstream development and packaging for a distribution are two totally
separated affairs, and mixing them only leads to huge headaches and
duplication of efforts.

I see where you are coming from with that, but for me as a lonely
developer they really aren't separate.  I don't want to go the
autotools route, of having a build tool that can also do installs, and
then translating an installation into packages and so on.  From my
point of view I'd like to make/download/sync a project, have the build
tool turn it into something I can install, and then use a package
manager to install it.

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.

Sure, if most devs are like me they won't always be making perfect
packages that go straight into a distro, but they will shift the job
of installing things to something that is good at it.

I don't see that it can hurt to have package information in the
project itself, even if no distro ever wants to use it.  Or am I
missing something there?

The problem with having support for making packages inside a build system is
that it encourages developers to actually use that support.

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.

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.

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.

Upstream developers should be able to only care about the code.
Distribution-specific issues and quirks are better handled by downstream
maintainers.

--
Andrea Bolognani <eof kiyuko org>
Resistance is futile, you will be garbage collected.

Still, it's all just some ideas at this point.

-- 
Phil Housley



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