Re: Debian packaging

From: Ricardo Yanez <>
Date: Sat, 23 Jul 2005 09:19:03 -0400

Hi Christian,

I have the 4.04.02 source, downloaded CVS-wise yesterday. I ran,

	fakeroot debian/rules debian/control

Next I do a

        fakeroot debian/rules binary

cint/src/v6_auxu.cxx:671: error: 'pattern' was not declared in this scope

cint/src/v6_auxu.cxx:673: error: redefinition of 'char* string'
cint/src/v6_auxu.cxx:37: error: 'char* string' previously declared here
cint/src/v6_auxu.cxx:674: error: expected unqualified-id before '{'
cint/src/v6_auxu.cxx:133: error: storage size of 'arg' isn't known cint/src/v6_auxu.cxx:39: error: storage size of 'argv' isn't known make[1]: *** [cint/src/v6_auxu.o] Error 1 make[1]: Leaving directory `/home/yanez/packages/tmp/root-4.04.02' make: *** [build-arch-stamp] Error 2
debuild: fatal error at line 842:
couldn't exec fakeroot debian/rules:

This is clearly NOT related to your automatic debianization script.

Nevertheless, I've been trying to compile and debianize your way to put ready-to-ship packages in my site, but the error above has prevented me from doing so.

Question. Why don't YOU make packages and put them in a site for distribution? Sorry to say, but the scripts are cumbersome. You need to figure out libraries and such needed for compilation. Moreover, you need to have some experience debianizing. For example, the package debhelper needs to be installed, which is not installed in your system by default.

Just to make a point, I uninstalled from my system all develepment packages and additional libraries not part of my normal system. Then I tryed to compile root, using the scripts.

$ build/package/lib/
$ fakeroot debian/rules debian/control
Making debian/control (special)
$ fakeroot debian/rules binary
Making debian/libroot.postinst from debian/
Making debian/ from debian/
Making debian/root-cint.postinst from debian/
Making debian/root-cint.postrm from debian/
Making debian/root-cint.prerm from debian/
Making debian/root-proofd.init from debian/
Making debian/root-proofd.postinst from debian/
Making debian/root-rootd.init from debian/
Making debian/root-rootd.postinst from debian/
Making debian/root-xrootd.init from debian/
Making debian/ttf-root-installer.postinst from
Making debian/ttf-root-installer.prerm from debian/
# Add here commands to configure the package.
./configure --prefix=/usr                               \
            --mandir=/usr/share/man/man1                \
            --docdir=/usr/share/doc/root                        \
            --cintincdir=/usr/lib/root/cint     \
            --etcdir=/etc/root                  \
            --with-sys-iconpath=/usr/share/pixmaps      \
            --enable-table --enable-ruby --enable-qt --enable-pythia
--enable-xrootd --enable-shared --enable-soversion --enable-explicitlink
--disable-rpath --disable-afs --disable-srp --disable-builtin-freetype --disable-builtin-afterimage
Configuring for linux
Disabling enable_rpath
Disabling enable_afs
Disabling enable_srp
Disabling enable_builtin_freetype
Disabling enable_builtin_afterimage

Checking for libX11 ... no
configure: libX11 (package x11-devel) MUST be installed make: *** [config.status] Error 1

I figure out the dev packages I need by an iterative try-and-fail procedure. The packages, in sequence, I need to pass the fist hurdle, that is configure, are:

libx11-dev, libgd2-xpm-dev

and dependencies. I don't know the outcome of this yet because of the compilation error mentioned above. Point is though that you need some experience packaging.

So, my proposal is: What if you made the packaging and ask people around the world to distribute your packages? I'll be happy to accomodate your packages in my site, any way you want them, as I'm sure a lot of people out there also would. You could have a master site from which Root mirrors sync. You could even ask people to make special DNS entries like root.myown.domain (I could) and maintain an official list of mirrors for people to consult before installing. A happy thought.


On Tue, 2005-07-12 at 17:10 +0200, Christian Holm Christensen wrote:
> Hi Ricardo,
> On Tue, 2005-07-12 at 08:25 -0400, Ricardo Yanez wrote:
> > On Fri, 2005-07-08 at 11:48 +0200, Christian Holm Christensen wrote:
> > > Hi Richardo,
> > > I'd like to discourage this kind of dual effort. If you have some
> > > problem with the way it's currently done, please write me (as I'm the
> > > one that does most of this packaging stuff in the first place) or
> > > possibly the list, and we can discuss it. The ROOT team is quite
> > > willing to make reasonable modifications to advance system integration.
> > >
> >
> > Basically, you want to turn everything "on", that is, compile and
> > package with all available support. If I want, say, Python support, I
> > would anyway have to configure and compile the old-fashioned way.
> Why? If the python can be build on the target platform, the 2 commands
> build/package/lib/
> fakeroot debian/rules debian/control
> will put the relevant stuff in `debian/control', and similar for other
> stuff.
> The reason that the scripts try to compile as much stuff as possible, is
> due to the way ROOT is build and distributed. After all, one can always
> de-select packages at install time.
> I'd prefer is ROOT was distributed in a slightly different way, so that
> there'd be one core ROOT (consisting of what is essential to ROOT only),
> and a number of plug-in packages. So one would have a CVS repository
> like
> -+- root # The core
> +- root-plugins
> | +- gl
> | +- mysql
> | +- sapdb
> | +- globus
> ...
> +- root-contrib
> +- xrootd
> ...
> and the requirement would be to install `root' first, and then build
> what ever appropriate plug-ins later. This would also ease the
> maintenance of ROOT, in that different groups could have write access to
> the various plug-in directories. This architecture could be expanded to
> the run-time environment, so that plug-in packages would put loadable
> modules in some directory (say <prefix>/lib/root/plugins), and some sort
> of registration script in another directory (say
> <sysconfig>/root/plugins). It wouldn't actually be so hard to do this,
> as most of the infrastructure is there already.
> > The
> > script, although pretty elegant, gives you a generic ROOT
> > compilation.
> I'm not sure I understand what you mean by `generic' here. I'd argue
> that it's actually gives you a rather particular set of packages that
> matches what can be build on the target machine.
> > Why not have a full featured debian directory in the source
> > tree instead, that fully complies with Debian Policy?
> Well, what
> build/package/lib/
> fakeroot debian/rules debian/control
> basically does, is to make that directory, that fully complies with the
> Debian Policy. These two lines (which are in the `debian' target of the
> Makefile), does exactly what a maintainer normally does by hand - it
> prepares the sources for Debian package building, and the `.diff'
> reflects that.
> > > I think you should use the normal ROOT Debian packaging stuff at this
> > > repository, to not confuse things too much. Anyway, good to see that
> > > you are willing to put the packages out there (even though the license
> > > technically forbids it :-)
> > >
> >
> > What do you mean? The source is intact, as required by Debian, except
> > that I have removed the Microsoft TT fonts, freetype and afterimage
> > tarballs and force-compiled with the versions distributed by Debian. The
> > debian directory in created on the fly with the help of the diff file
> > when you apt-get the source. If you don't want this, you can download
> > the source the normal way and use the
> The hick-up, is the line
> Additionally, the authors grant permission to modify this
> software and its documentation for any purpose, provided that
> such modifications are not distributed without the explicit
> consent of the authors and that existing copyright notices are
> retained in all copies.
> in the ROOT license. Debian's reading of this, is that for Debian
> packages you need an `explicit consent' from the authors, even though
> not a single source line has changed. Debian is reading this rather
> strictly, so that `modifications' also encompasses repackaging, even
> thought that might not be the spirit of the licence.
> Yours,

Ricardo Yanez
PO Box 156
Penaflor CHILE
phone: +56 2 8140550
mobile: +56 9 5112241
PGP public key: 5B625B93
Received on Sat Jul 23 2005 - 15:20:57 MEST

This archive was generated by hypermail 2.2.0 : Tue Jan 02 2007 - 14:45:10 MET