In article <000101c19ea9$07993fb0$0b02a8c0@home> you wrote:
> [...]
> Makes sense to get an initial release out. I'm finding though that
> software like KDE complains about not being able to link w/ shared
> libraries.
Yes, it's the used GNU libtool and the (correct) way KDE uses libtool.
> I'll build my spec files using them as it's a bit cleaner,
Sure.
> but definitely more of a headache to track the underlying library
> dependencies.
I don't think that dependencies are harder, because in OpenPKG we never
have file-based dependencies. We only use package-based dependencies.
And these are the same. The difference is just that in addition to
build-time deps, with shared libraries you also have run-time deps.
> Perhaps start a separate thread on the different linking
> types (e.g. using -R or -rpath, vs. using LD_LIBRARY_PATH, vs. something
> that I'd like to try, using relative paths (using the Solaris linker)).
Just FYI: for KDE you don't have to fiddle around with all this, because
KDE uses GNU libtool and this beast already knows all the details.
Packages we are not based on libtool inherently make trouble if you want
to be cross-platform. So I do not recommend fiddling around with those
things yourself.
> [...]
>> So, can you reword the question or explain in detail what issue you
>> address here. Where have we disabled ncurses or miss dependencies?
>
> Perhaps this gone awry would be the recent experience I had of trying to
> build a Mandrake RPM which relied on ghostscript which relied on
> 'printer-drivers' which relied on a TON of other packages. I think
> their dependencies are actually too great. But what I mean is that
> (taking the ncurses example), using ./configure your packages 'leave
> out' a lot of stuff that could be 'found' by the configure script. For
> example, using --enable-ncurses vs. --disable-ncurses. A possible
> direction I'm thinking about is to identify in the BuildRequires and
> Requires which packages add to the functionality of a given package, vs
> which are really needed to be built.
>
> An example of this is when the configure scripts check for say 'flex'.
> On a typical linux distribution a package whose configure script checks
> for this would say BuildRequires: flex in the .spec file. How can we
> distinguish between
> 1) That program is really needed
> 2) A substitute is okay (e.g. lex)
> 3) That program/library just results in it being used rather than
> substitution code that's in the .tar.gz (e.g. using the system makeinfo
> rather than building a custom one for gcc)
> 4) That program just extends the features of the package to build
Ah, now I see your point. Hmmm... usually you have to check this in
detail for every package and this can be very complicated. OTOH if you
want to be self-contained and cross-platform you very often are _forced_
to force the packages to build against your own supplied things --
independent whether it extends the feature set or not. So, in OpenPKG's
practice I think one has not very much choice. The only choince we have
(and which you correctly identified) is whether we should require the
minimum (just that it works) or the maximum (to have a full featured
thing).
This is hard to answer. My usual way of the past was to add
%defines and %ifs to the .spec to being able to serve both
situations. See the (horribly complex) apache.spec of OpenPKG.
It allows (by default) the building of a plain Apache, but with
just a few "yes" defines at the top of the .spec you can build an
Apache+mod_ssl+OpenSSL+mod_perl+Perl+whatever combo. I dislike the fact
that those %ifs trash the .spec file, but for the users it is usually
the best solution.
> [...]
> I definitely like keeping the .spec files clean. Another thread to
> start would be what 'features' make the OpenPkg distribution be more
> than a set of packages and more like an integrated user environment.
> Installing info files is one, adding programs to the KDE/GNOME/CDE menus
> would be another.
Agreed.
> [..]
> Okay well, the first .specs I'll contribute then will be on getting KDE
> to work. The cross-platform stuff is gonna be tough though since I've
> only now got access to a Solaris box (though could do a virtual server
> on a linux box).
BTW: Base your stuff on the "x11" package from OpenPKG CURRENT the way
"gtk" does it already, please. If you get it running under Solaris you
can be sure we together get it running on the other platforms, too.
Usually it is the other way round: OpenPKG is primarily developed under
FreeBSD, but (inside C&W) primarily used on Linux and Solaris. And often
I already have it running fine under FreeBSD, but Solaris still breaks
;)
> For KDE, there seems to be a major sensitivity to what compiler one is
> using. Gcc.3.0.x in general has been a pain
> [...]
Yes, I know. Hopefully with our GCC 3.0.3 and the latest KDE 2.2.x it will
work...
So, install the bootstrap "openpkg" and the "x11" and "gcc" packages and
start hacking on the KDE packages. If you have something share it with
us on openpkg-dev and we try to help.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [EMAIL PROTECTED]
