Hello all,

I am preparing a package that I will submit for review, and hopefully later, for inclusion in Fedora.* However, I have run into some issues which I cannot seem to resolve myself. I write to the list, hoping that some of you may be able to help me resolve the issues.


First, let me tell you a little bit about the program, as its important to the issues on hand.

The program is called ROOT, it is a whole analysis framework developed by CERN that is currently in use in most high energy to medium energy physics laboratories, and released under the LGPv2+. However, it is written general enough that it can be applied to other fields that require a complex analysis framework.* Additionally, ROOT makes use of an internal C/C++ Interpreter, which allows for on the fly scripting of C/C++ code.


So essentially, ROOT is both an analysis package, and a development package, which really leads into the next problems.

1) the C/C++ interpreter called CINT, produces, as output, DLL files.* I don't know why, but this is their solution to dynamic libraries that will be shared across all supported OS's.* They support Linux and many Unices, as well as Mac OS X and Windows.* These DLL files are compiled by the code, so we have the source code available, though rpmlint seems to give a warning about them.* And essentially, I don't know what to make of it.


Here is a sample error: root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/include/stdcxxfunc.dll

2) Because rpmlint used to complain about header files being in a non devel package, I moved all header files to the devel package.* But the devel _MUST_ be installed along with the main package, CINT requires them to be there.* So if I don't create a devel package, I get hundreds of warnings for the header files.* If I do create a devel package, and require this devel package from the core files, I get an error out of rpmlint.


3) This one is not really an I issue I guess, but I figured I might as well mention it now.* ROOT ships with MS TrueType fonts, for some reason.* So I just removed them from the package, as I have not had any problems without them on Fedora.* And I use root extensively.* Also, I've removed some windows DLL's that were included in the package.* Also not needed for a Fedora release.* I am hoping that this will not be a problem, having a tar archive that is slightly different than the upstream one.


Thank you all for your advanced help.* I really hope this program can be made fit to include in the distribution.


--Juan Carlos Cornejo

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Sun, Jun 15, 2008 at 09:27:20PM -0400, Juan Carlos Cornejo wrote:
> Hello all,
>
> The program is called ROOT, it is a whole analysis framework developed by
> CERN that is currently in use in most high energy to medium energy physics
> laboratories, and released under the LGPv2+. However, it is written general

It would indeed be very nice to have ROOT in fedora. I'd be happy to
review it.

> enough that it can be applied to other fields that require a complex
> analysis framework. Additionally, ROOT makes use of an internal C/C++
> Interpreter, which allows for on the fly scripting of C/C++ code.

I guess it is similar with comis from the cernlib? Though there doesn't
seems to be a corresponding interpreter in the cernlib it seems to do
the same.

> 1) the C/C++ interpreter called CINT, produces, as output, DLL files. I
> don't know why, but this is their solution to dynamic libraries that will be
> shared across all supported OS's.

The dynamic libraries cannot be shared accross different OS? They have
to be recompiled? In any case it is a bit strange for an interpreter to
produce long lived output. Is a cmopiler used while interpreting, that
would defeat the interpretation?

> They support Linux and many Unices, as
> well as Mac OS X and Windows. These DLL files are compiled by the code, so
> we have the source code available, though rpmlint seems to give a warning
> about them. And essentially, I don't know what to make of it.
>
> Here is a sample error: root-devel.x86_64: W: unstripped-binary-or-object
> /usr/lib64/root/cint/include/stdcxxfunc.dll

dll on linux are in general called along stdcxxfunc.so. I guess that the
script that does the stripping and collect the debugging informations
don't know about objects ending in .dll. Also the objects should be
executables. In that case, you'll have to either have cint do .so files
or tweak the debuginfo generating script such that it also find files
ending in .dll.

> 2) Because rpmlint used to complain about header files being in a non devel
> package, I moved all header files to the devel package. But the devel
> _MUST_ be installed along with the main package, CINT requires them to be
> there. So if I don't create a devel package, I get hundreds of warnings for
> the header files. If I do create a devel package, and require this devel
> package from the core files, I get an error out of rpmlint.

Is cint really needed for root to work? This seems wrong to me.

Anyway, there are some exceptions for cases like this one. In that case
you have to end up ignoring some rpmlint errors. I don't think it is
possible to have guidelines about these cases since they are all
different. Sometime it is better to have the headers in a non-devel
package, sometime it is better to have a non devel package depend on a
devel package and there are certainly onter cases.

There were some discussions about thosdee issues in the past, but there
seems to be nothing in the guidelines reflecting it. In the
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
it is a MUST to have header files in devel packages, for example.

> 3) This one is not really an I issue I guess, but I figured I might as well
> mention it now. ROOT ships with MS TrueType fonts, for some reason. So I
> just removed them from the package, as I have not had any problems without
> them on Fedora. And I use root extensively. Also, I've removed some
> windows DLL's that were included in the package. Also not needed for a
> Fedora release. I am hoping that this will not be a problem, having a tar
> archive that is slightly different than the upstream one.

It is covered in
https://fedoraproject.org/wiki/Packaging/SourceURL#When_Upstream_uses_Prohibited_Code

> Thank you all for your advanced help. I really hope this program can be
> made fit to include in the distribution.

I hope too.

I think that the best would be that you begin a submission, even with
somthing you know isn't ready for acceptation, such that the issues can
be tracked in bugzilla, and that we can see the actual code.

--
Pat

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

>>>>> "PD" == Patrice Dumas <pertusus@free.fr> writes:

PD> It would indeed be very nice to have ROOT in fedora. I'd be happy
PD> to review it.

It should be noted that "root" is a rather ambiguous package name; I
hope that there's some reasonable name that can be used.

- J<

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Mon, 16 Jun 2008, Jason L Tibbitts III wrote:


"PD" == Patrice Dumas <pertusus@free.fr> writes:


PD> It would indeed be very nice to have ROOT in fedora. I'd be happy
PD> to review it.

It should be noted that "root" is a rather ambiguous package name; I
hope that there's some reasonable name that can be used.


You'd think that, alas, this is not to be so.

I had to deal with root for years. It likes to run a daemon named 'rootd'.
There's nothing that makes a sysadmin cringe up like a process named 'rootd'


-sv

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

>>>>> "SV" == Seth Vidal <skvidal@fedoraproject.org> writes:

SV> You'd think that, alas, this is not to be so.

Well, we can at least choose a reasonable name for the Fedora package;
renaming the daemons and executables is probably a bit much to ask,
unless they conflict with those from other packages.

SV> I had to deal with root for years. It likes to run a daemon named
SV> 'rootd'. There's nothing that makes a sysadmin cringe up like a
SV> process named 'rootd'

I can only imagine what happens when a user says "I need root on my
machine".

- J<

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Hi all,
*** Sorry for such late response, my laptop just died :'(( and since I'm in a conference, I have limited computer access.

As for the name, yes, it was one of my primary concerns.* I figured that would have been resolved at the end.* I thought about perhaps naming it root-analyzer.




At Jefferson Lab, where I'm at, we have our own version just called Analyzer.* And it's very common to just think of it as root-analyzer.* So that might work as a name.* If need be, I guess I'll have to dwell into the code and change the names of the binaries and various daemons.




I submitted the spec and source file in for review.* Thank you all for your early pre-reviews.

--Juan Carlos

On Mon, Jun 16, 2008 at 12:19 PM, Jason L Tibbitts III <tibbs@math.uh.edu> wrote:



>>>>> "SV" == Seth Vidal <skvidal@fedoraproject.org> writes:



SV> You'd think that, alas, this is not to be so.



Well, we can at least choose a reasonable name for the Fedora package;

renaming the daemons and executables is probably a bit much to ask,

unless they conflict with those from other packages.



SV> I had to deal with root for years. It likes to run a daemon named

SV> 'rootd'. There's nothing that makes a sysadmin cringe up like a

SV> process named 'rootd'



I can only imagine what happens when a user says "I need root on my

machine".



*- J<



--

Fedora-packaging mailing list

Fedora-packaging@redhat.com

https://www.redhat.com/mailman/listinfo/fedora-packaging



--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging