On 3/25/06, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: > If you really want a multi-distro spec you need to depend on actual > filenames, not package names (to get around package naming mismatches), > and do define tricks when the files themselves moved > > (see > http://www.jpackage.org/cgi-bin/viewcvs.cgi/rpms/free/mod_jk/mod_jk.spec?root=jpackage&view=markup&rev=1.1.2.5.2.6 for a real convoluted example) Thanks. Looking at your example, I came up with the following: %define xinclude %( if test -d /usr/X11R6/include; then echo /usr/X11R6/include; else echo /usr\/include; fi ) ... BuildRequires: %{xinclude}/X11/StringDefs.h, %{xinclude}/X11/Xlib.h BuildRequires: %{xinclude}/X11/Intrinsic.h, %{xinclude}/X11/Xatom.h I don't know enough about what packages create what directories to know how close to foolproof the above test is, but the only alternative I can see is checking the redhat-release file, and that's not very reliable either. > > As for building a single binary and using it everywhere I really would > not advice it, even it you do static linking. It's far safer to rebuild > the package on the actual distro(s) targeted The obvious trouble with that solution is that I am a single individual with limited resources and funds. I don't have the time, the equipment or the money to invest in a farm of computers running multiple versions of Redhat, Mandriva and Suse. Using Qemu or some other emulator would help, but I still need more memory and more disk space than I have today. Also, the list of downloads is too long already, I don't want to provide 20 more downloadable files. > > Unless you want to learn far more about glibc internals that you ever > wanted to know I was under the impression that as long as you only use standard C library functions, the LSB would mean that you are reasonably safe. Oh well. I guess this means that the only solution I have is to provide tarballs and hope that people on the respective distros will start packaging things themselves. I guess it might happen, there are already packagers for debian, gentoo, arch and rpath. But it still leavs a sour taste - elf-based libraries are supposed to be so much more advanced than Windows dll:s, but still library versioning seems to be no better (possibly worse) than under Windows. Oh well, I guess it's not RPM:s fault. > > -- > Nicolas Mailhot > -- Axel _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
