Re: Want to add to contrib.... xmldbx

On Mon, Jan 30, 2006 at 10:25:39AM +0100, Thomas Hallgren wrote:
> >Actually I don't think it would be all that hard. You just need to have
> >each project produce an xml file with bits of package information (name,
> >dependencies, version info, etc...) which could then be combined with all
> >the other packages to produce a complete list of available packages.
>
> While I'm all for the idea, I don't think the effort should be
> underestimated. At least it must be *very* well scoped. Chances are, it
> becomes extremely huge and complex task. Here are some thoughts that might
> be worth considering:

<snip>

To be honest, I think XML is way overkill. Simply provide a makefile
that has the targets install-check, build and install and maybe also
check. Provide a standard way for people to download projects.

CPAN is a nice example, but really it's mostly a frontend to makefiles.

IMHO, stuff on PgFoundry it not going to become popular because we put
links there. It's going to become popular if/when other distributors
can write things like:

for i in <list of projects> ; do
download package
unpack
make install-check (check if dependacies are good)
make build
make install
build package from installed stuff
done

If the makefiles support DESTDIR and a few other such variables,
something like Debian could make a postgresql-goodies. Currently Debian
provides contrib because it's got a standard method of compiling. A
good test is just unpacking the project in the contrib directory of the
postgresql source and running make. If it produces something that
works, you've got the problem licked.

Similarly for RPMs, if a standard top-level spec file can make a
working package, it's going to be easier for other people to
incorporate.

> >You then
> >just need a binary installed with postgresql that can grab the latest copy
> >of the xml list so it can present a list of packages to install. It then
> >downloads the packages from pgfoundry directly.

I suppose the only thing that really needs to happen is some kind of
index that can be downloaded so people can find stuff. And so an
automated program can actually download the right file. I think
worrying about dependancies at this stage is overkill. Let get things
to the stage where people can say:

$ make install-check
*** Sorry, foomatic 1.07 must be installed

And then we can worry about automatically resolving them.

> Some packages have dependencies to packages that already provide such a
> structure (CPAN, Ruby, Maven, to name a few). A packaging tool that make
> things easy to install must be able to cope with that too, which makes
> things even worse.

I don't think that's a real issue. For example, I use Debian. If
something on PgFoundry has been packaged as a Debian package, I'm ten
times more likely to install it than otherwise. What we should be
aiming for is making stuff easy enough to install so that someone in an
afternoon can download 10 projects and create 10 Debian packages, 10
Redhat packages or 10 MSI installer packages.

This is a much easier task for us because only have to provide the
mechanism but not all the handholding. It also means the end result is
something that integrates with the users system better because the
packager can tweak it for the environment, and the author doesn't need
to care.

Indeed, most of the popular pgfoundry projects have already been
packaged. Which was first, the popularity or the packaging?

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.