Hi Christian,
I have the 4.04.02 source, downloaded CVS-wise yesterday. I ran,
build/package/lib/makedebdir.sh 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 '{'
token
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.
Making debian/libroot.postinst from debian/libroot.postinst.in Making debian/root-bin.menu from debian/root-bin.menu.in Making debian/root-cint.postinst from debian/root-cint.postinst.in Making debian/root-cint.postrm from debian/root-cint.postrm.in Making debian/root-cint.prerm from debian/root-cint.prerm.in Making debian/root-proofd.init from debian/root-proofd.init.in Making debian/root-proofd.postinst from debian/root-proofd.postinst.in Making debian/root-rootd.init from debian/root-rootd.init.in Making debian/root-rootd.postinst from debian/root-rootd.postinst.in Making debian/root-xrootd.init from debian/root-xrootd.init.in Making debian/ttf-root-installer.postinst fromdebian/ttf-root-installer.postinst.in
./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
Disabling enable_rpath Disabling enable_afs Disabling enable_srp Disabling enable_builtin_freetype Disabling enable_builtin_afterimage
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.
Regards,
Ricardo
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/makedebdir.sh
> 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
>
> cvs_at_root.cern.ch:/user/cvs -+- 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
> > makedebdir.sh 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/makedebdir.sh
> 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 makedebdir.sh.
>
> 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 email: Ricardo.Yanez_at_correo.calel.cl jabber: ricardo.yanez_at_jabber.org web: http://www.calel.cl/ PGP public key: 5B625B93Received 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