Hi Nicholas,
I'm with you on the frowning on this practise. But until a segfault in
gfortran.so.1 (gcc 4.1.x) is fixed, I can't build an important package
that I need on Fedora Core 5. Just not possible.
To add a little more background: the troublesome code here is an
optional closed source (but nevertheless very desirable) plugin from an
outside developer. I've got limited permission to compile and distribute
binaries for the plugin (to licensed users of the plugin) with our main
(open source) application. I'm not about to debug/rewrite the code in
question, and I don't care too much about portability and finesse with
this plugin: if I can kludge together an RPM that works for FC5 users,
then I'm happy. I don't necessarily need it to *build* on FC5, just to run.
The alternative is to package up the FC4 libfortran.so.0 file in a new
libgfortran package (eg libgfortran0-4.0.2-0.i386.rpm) that is named
differently such that updates to the official libgfortran don't
conflict/replace the special FC4 libgfortran package. That would be
cleaner but then our binary RPM would need to be distributed along with
that additional file.
Given that as soon a fixed gfortran 4.1.x comes along the whole problem
goes away (and the stray libgfortran quietly disappears), it seemed to
me that bundling libgfortran.so.0 with the plugin binary was a bearable
kludge. Maintenancewise, this seems tidier than leaving libgfortran0
floating around on people's systems.
Regarding legal issues, I'm thinking that distributing compiler runtime
libraries alongside code generated by said compiler must surely be
allowed and not a problem.
Cheers
JP
Nicolas Mailhot wrote:
Le dimanche 30 juillet 2006 à 12:03 +1000, John Pye a écrit :
I could either
create a new (separate) RPM that just contains the older libgfortran, or
I could just include the file inside my package (and add a "Provides:
libgfortran" tag of some sort, perhaps). I was thinking that I would use
an %if statement inside my .spec file that would test which distro I was
building for (either using the 'dist' variable, or perhaps using "--with
bundled_gfortran") and depending on which one it was, either include
libgfortran in the RPM or not.
Do that and a lot of people won't ever touch your packages with a
10-foot pole. Bundling unrelated libs in a package, especially because
you can't figure how to build with the new distro-supplied version, is
strongly frowned upon. (also the legal and maintenance side-effects are
interesting)
------------------------------------------------------------------------
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
--
John Pye
Department of Mechanical and Manufacturing Engineering
University of New South Wales, Sydney, Australia
http://pye.dyndns.org/
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
