True. However, the reason i'm here: the rpm dependency structure is something that all rpm based distro's encounter, it's not mandrake specific.I'll definitely take a look!Maybe also take a look at:
http://eijk.homelinux.org/~stefan/slbd.html
The main reason why I'd like a solution for the -devel dependency
problem is to make automatic rebuilding possible / more reliable. The
script relies heavily on urpmi (mandrake's up2date), so it's not
useable on Redhat...
For something mandrake specific, that should be an issue of mandrake, not rpm.
I prefer to build my packages with basesystem + rpm-build + BuildRequires installed only. After every package build the script brings the system back to the bare (basesystem + rpm-build) state.A refresh, with telling it to install the -devel files, and while it'sThis is true, but only if you chose not to install devel by default.
at it, also do the same for the packages it Requires (otherwise you'll
have missing -devel files down the line).
Yes, that'll work.This is not possible if you have multiple versions of libraries installed on the machine. These packages (if the -devel files were contained in them) would have conflicting files:
libgtk+-x11-2.0_0-2.2.1-2mdk
libgtk+1.2-1.2.10-32mdk
libgtk+2.0_0-2.2.1-2mdk
If you are going to have multiple versions of the same library then you really should do what Red Hat does with BerkeleyDB where there are subdirectories for the includes.
IE /usr/include/gtk+1.2 and /usr/include/gtk-2.0
Same at mdk: $ urpmf gtk.h | grep include libgtk+2.0_0-devel:/usr/include/gtk-2.0/gtk/gtk.h libgtk+1.2-devel:/usr/include/gtk-1.2/gtk/gtk.h
Yes. I guess they've organized it the right way.In fact - Red Hat does that with gtk and I have devel headers for both gtk+1.2 and gtk 2.0 installed on my system right now and they do not conflict with each other.
This can be done in a spec file that will build on any distro - %files blah %devel %_includeddir/%name-%{version}/*.h
gtk+1.2 and gtk+-2.0 could even then have the same name and the two could be installed side by side with the -i option with no conflict.
More and more of them do. The issue is that different distributions
have different ways of packaging. The main problem (IMHO) is that
there is no (cross-distro, LSB?) package naming standard. But this is
a different discussion :-)
Mostly a problem for Perl modules. If some sanity is observed, such as using the name of the tarball for the package name, this is avoided.
If the developer provides a spec file, then every vendor should use the naming scheme of the developer, or at least have a "provides" with that in it, and a BuildRequires or Requires should use the naming scheme of the vendor who makes the package they depend upon (if applicable).
A registry similar to the one that exists mime types would be nice - I think LSB wants to do that.
I would be more interested in the LSB specifying what kernel headers glibc should be compiled against then to have them meddle in some of what they want to dictate (such as how many runlevels to have ...)
It would be cool if it could be done... But it sounds complicated.Which means that the provides would have to change if the -devel files
were installed / no installed?
Yes. If the package has devel headers and the user did not specify that they not be installed, then the provides database should be updated to have %{name}-devel added to it. That is what I propose.
??I'm not convinced...* of package "B", the -devel files of package "A" (which BThe devel files from "b" don't always need the devel files from "a"
depends on) will also be installed?
devel packages contain header files and sometimes static libraries -
afaik, they don't require any other devel files to be installed - some
packages use the headers to build might, but the devel package itself is
usually just header files and static libraries. Shared libraries are
part of the regular package.
Take this buildoutput as an example: http://eijk.homelinux.org/build/cooker/i586/problem/xpp-1.1-8mdk.src.rpm.txt
You'll see that the header files that are in XFree86-devel are missing
==> XFree86-devel is not installed.
imho that is a broken configure script.
And what if they aren't installed on the system, due to a missing dependency?The configure script should look for the X11 headers so that the proper include dir can be specified to the Makefile.
Xpp headers have no way of knowing where the X11 headers are included or whether you are using XFree86 or some other implementation of X11 (and multiple X Servers may be installed), the spec file for that package
^^^^ xpp or libfltk?
should require X11-devel (and XFree86-devel should provide X11-devel) and the configure script should fail if it can't find the X11 headers.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature