[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: devel packages




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.

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.

A refresh, with telling it to install the -devel files, and while it's
at it, also do the same for the packages it Requires (otherwise you'll
have missing -devel files down the line).


This is true, but only if you chose not to install devel by default.

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.

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

Yes, that'll work.

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

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.

Yes. I guess they've organized it the right way.

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 ...)


I looked up the lsb's proposed rpm naming scheme today... They want all lsb packages to be named
lsb<something>


What would be the logic behind this?

Wouldn't it actually causes more problems than it solves?

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.

It would be cool if it could be done... But it sounds complicated.

But this is what I meant with a packaging system within a packaging system...

* of package "B", the -devel files of package "A" (which B
depends on) will also be installed?


The devel files from "b" don't always need the devel files from "a"
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.


I'm not convinced...

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.


??

The configure script is doing it's job... nothing wrong there...

The configure script should look for the X11 headers so that the proper
include dir can be specified to the Makefile.

And what if they aren't installed on the system, due to a missing dependency?

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.


When you want to build something which Requires libfltk-devel to be installed, XFree86-devel ALSO needs to be installed.


libfltk-devel Requires XFree86-devel.

Problem is, that currently a developer will need to specify this in the .spec file of libfltk, that for the sub package -n -devel: Requires: XFree86-devel.

But this doesn't happen. And it isn't an exception. It's very common.

That's why I'm argueing that -devel package dependencies are broken.

Stefan

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []