Re: Re: Make Redhat (again..)

Christian Holm Christensen wrote:
> No. I meant that in the spec file, one could do something like
>
> nzgipped=`ls %_builddir/usr/share/man/man1/*.1.gz | wc -l`
> if test $ngzipped -lt 1 ; then
> # transform names according to the RedHat scheme.
> else
> # transform names according to the Mandrake scheme.
> fi
>
> It's ugly, but it may work.
>

In the patch file you'll see a different solution based on extension written
in the rpm script brp_compress. I hope you'll agree

> Another solution would be to test if one is on a Mandrake system. Does
> the file `/etc/mandrake_release' (or similar) exist on Mandrake?
>

yes, there are 3 links in /etc (redhat-release, mandrake-relese, release)
pointing to mandrakelinux-release

>>Rpm is a very precise tool, and it does not allow you to package if it knows
>>that some files you wait for are not in the build dir; but also the
>>contrary is
>>true. The error I told before is of the first kind but now I have a second
>>kind.
>
>
> RPM isn't that strict. Consider DPKG, and you'll see a strict package
> builder :-)

I'll see it..

>>11 files that are in the build root but there are no packages that claims
>>for them :'(
>>
>>the first 8 are
>> /usr/include/root/TFoam.h
>> /usr/include/root/TFoamCell.h
>> /usr/include/root/TFoamIntegrand.h
>> /usr/include/root/TFoamMaxwt.h
>> /usr/include/root/TFoamVect.h
>> /usr/lib/root/libFoam.so
>> /usr/lib/root/libFoam.so.4
>> /usr/lib/root/libFoam.so.4.04
>
>
> That's because the proper entries in `configure',
> `build/package/common/', etc. wasn't added when the plugin `foam' was
> added. Please refer to `build/package/debian/README.Debian' for how to
> add additional plugin packages. If you do what's listed there, please
> mail a patch to me and Fons.
>

Ok, I've done my homeworks..

I don't know if foam is a plugin, I have seen that a list is generated by makelist
scripts but I've not understood if this is a default behaviour or if your scripts find
the info somewhere. But as I already told you, the problem to generate a subpackage for
this plugin (if it is) is only due to a lack of info about this plugin. I've carefully read all the steps necessary to do that and but description is still an unknown
stuff to me; anyway all my work would have been to a add a simple row in configure and all the things
carefully descripted in your README.debian. But I think that if foam would be a plugin, Fons Rademakers
would be disappointed to have not added a proper entry in the configure with all the necessary
things to correctly handle all the part of his (optional) building; so taking into account that
a description has to be written anyway by someone who knows what has to be written, that a configure
must be written by a person who know all the details of this plugin and so on, and, last but not least,
I'm not sure if it's a plugin I found another solution only adding 5 characters to mekelists.sh.
With this, foam libraries and headers are no more unknown files but are added to development
libraries (as I think it should be).
If you want a subpackage I'll be glad to provide, but I need some other infos

>
>>others 2 are
>> /usr/share/man/man1/olbd.1.bz2
>> /usr/share/man/man1/xrootd.1.bz2
>>
> I added these man pages as Debian _requires_ that all binaries in
> `/usr/bin', `/usr/sbin' and so on have man pages. However, I did not
> protect against them not being used in case XRootd wasn't build. Some
> code in `Makefile' is needed.
>

I know that is required for binaries to have their own man pages, and I agree
that something in Makefile should be changed to build man pages only for
binaries that are builded; but I understood also the philosophy behind this choise
(if any): build a man page is a simple task that can be accomplished once for all,
regardless its binary.
This strange behaviour does not disturb the installation without RPM, so I made a patch
to not be bored by RPM. Unfortunately man pages seems to not be tagged as
documentation, so with this patch exceeding files do not produce errors at all, but you'll be
warned anyway during the install stage.
If you think that man pages are correctly tagged as docs, let me know: maybe it's a Mandrake's bug.

>
>>the last is
>> /usr/share/root/macros/html.C
>>
>>what's that? Every suggestion is welcome
>
>
> That's a script to generate the HTML documentation. It should go into
> the `root-bin' package. The appropriate line added to
> `build/package/common/root-bin.install' should do the trick

patched

Another patch has been made:
In the README/INSTALL there are suggestions about RPM building; it's written to prepare a tar ball

cd ..
mv root root-<version>
tar -czvf root_v<version>.source.tar.gz root-<version>

The name of tarball is correct because it matches wat is written in the Source field of spec file; but naming the parent dir of the tarball "root-<version>"
does not work..

%setup -n ${name}
unpacks the tarball but after will try to enter in a dir named "root" as the {name} variable
contains this.
without the "mv" command above it works but thinking about building different version of
ROOT I choose anothe name.
INSTALL and spec.in now are patched this way

I hope to have been useful..

Best Regards,

Germano

P.S: Is there any way to satisfy CERNLIB dependecy without remove them from spec file?

-- 
     \ | /
     (@ @)
-o00-(_)-00o------------
------------------------------------------------------------
Germano Percossi
University of Rome "Tor Vergata" and INFN Roma2
Via della Ricerca Scientifica 1
I-00133 Rome Italy
Phone     : 06 7259 4824
Room      : c0 28b
------------------------------------------------------------






text/x-patch attachment: root.germano.patch