Re: DD for Felix package requested
- To: Stefano Zacchiroli <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Re: DD for Felix package requested
- From: skaller <email@example.com>
- Date: Fri, 25 Aug 2006 12:22:39 +1000
- Message-id: <firstname.lastname@example.org>
- In-reply-to: <20060824192916.GC11151@aquarium.takhisis.invalid>
- References: <email@example.com> <20060821071522.GI5974@aquarium.takhisis.invalid> <firstname.lastname@example.org> <20060824143001.GC9176@aquarium.takhisis.invalid> <email@example.com> <20060824192916.GC11151@aquarium.takhisis.invalid>
On Thu, 2006-08-24 at 21:29 +0200, Stefano Zacchiroli wrote:
> On Fri, Aug 25, 2006 at 01:31:01AM +1000, skaller wrote:
> > Ok, done: name is 'skaller-guest'. Thanks!
> I've added your user to the pkg-ocaml-maint project. Please take some
> time to study the structure of our svn repository before committing
> stuff. Please shape the felix package so that it can be built with
> svn-buildpackage as the other packages.
> Ralf, do you remember where is the svn-buildpackage howto we prepared
> for our repository structure? It should be committed on the repository
> somewhere, but I can't find it right now ...
> Well, John, if you find it, it would be a good starting point :-)
I will make every effort not to make a mess .. possibly
asking many annoying questions. Sorry in advance but I have
no desire to screw up anyone else's work: I judge that
more annoying than just asking silly questions.
Although I HAVE used debian tools before I'm NOT an
expert, and I relinquished all the debian stuff to
Mike previously. It's hard to focus on upstream
development and also meet the stringent quality standards
of both debian and debian-ocaml-maint team.
I have a chroot made by debootstrap now for testing.
The main difficulty with the current Felix system seems
to be the rather large set of files, especially documentation,
which need to be installed. These are organised into
a tree, and whether a particular branch (subdirectory)
is available is partly dependent on whether a particular
component gets built.
The problem is that this is detected dynamically by the
build processes and can't be predicted in advance.
So the 'binary' packages may differ depending on whether
certain optional components are installed. These include
gsl, gmp, SDL
for example. This also impacts dependencies. My thought
is simply to build-depend all this stuff.. but I don't
know if it is available for all architectures. For example
I have no idea if gmp and SDL work on a Dec Alpha.
If I build-depend on them, and they're not available,
the whole package breaks.
Note: the *proper* solution here is already known:
multiple Debian packages. However this is WAY too hard
for me to implement at this point in time.
The Felix build system itself already uses its own
package manager, so we've made good progress factoring
the system into packages, in preparation for debianisation.
How is this handled by debian-ocaml-maint at the moment?
There must already be some packages with 'optional dependencies'
where the options must be known at build time, not just
Note that Felix itself is largely, but not completely,
isolated from this problem: bindings to, for example,
GMP, can exist whether or not GMP is installed on the
users platform. Unfortunately some packages aren't
suitably modular, for example this doesn't work with
SDL because of the (stupid IMHO) way SDL is constructed as an
framework rather than a library. We need a custom driver
for SDL, and it can only be created at build time if and
only if SDL-dev package is installed.
This also leads to the interesting scenario where you need
SDL-dev at build time, but you don't need even the binary
SDL library to install the binary package. Of course
the built SDL dependent driver won't work without it,
but a problem only arises if you use it. We can't
really 'depend:' on SDL, because Felix specifies it
as an optional component. But if the user DOES install
the SDL package, it has to be compatible with the
SDL-dev package used to build the driver.
I have no idea how to solve this in debian either.
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net