Comments interspersed below:
> -----Original Message-----
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
> On Behalf Of Ralf S. Engelschall
> Sent: Wednesday, January 16, 2002 7:17 AM
> To: [EMAIL PROTECTED]
> Subject: Re: FW: Duplicate Efforts
>
>
> In article
> <000101c19ddee9092e05707669D302D0C9F3D847F0F225D82B8b02a8c0@home> you
> wrote:
>
> > [...]
> > 1) Being able to have an RPM distribution sit parallel to the
underlying
> > OS (I've been using /opt/rpmsw).
>
> OpenPKG works with any root directory, so you will be certainly happy
in
> being able to stick with this ;)
>
> > [...]
> > So I'm thinking, why not join you guys.
>
> No problem, we are open for any contributors.
>
> > I really like that you've
> > modded the RPM source to make it more cross-platform. By contrast,
I've
> > just got a bunch of %ifos in the specfile which is messy.
>
> Yes, we generally try to completely avoid any OS-specific parts in our
> .spec
> files. Sometimes it is not entirely possible, but we were at least
able to
> have over 95% of all our .spec files totally independent of the
underyling
> OS.
> And if we really need OS-dependent things, we move it to the bootstrap
> package
> (into our "rpmtool", etc) so we at least can abstract from the problem
in
> our
> .spec files.
>
> > [...]
> > 1) Why is everything statically linked? On Solaris, the philosophy
is
> > to dynamically link everything. Could this be changed?
>
> The dynamic shared library usage is the philosophy on all modern Unix
> flavors since many years, of course. We use static linking mainly to
> avoid cross-platform trouble. Because with shared libraries you have
> to fiddle around with LD_LIBRARY_PATH (and/or ldconfig if existing)
> and especially can run into trouble for libraries which the OS vendor
> also provides (best examples: libdb, libz, etc.). In using only static
> linking we are a little bit less flexible and our object code grows
> in size, but OTOH we already avoid lots of trouble in advance.
>
> But we certainly will try to change this after some settlement of
> OpenPKG. At least it is on my list of tries for OpenPKG 1.2. So it
> certainly can be changed, but we have to evaluate first and make sure
we
> do not open a can of worms related to the cross-platform aspect.
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. I'll build my spec files using them as it's a bit cleaner,
but definitely more of a headache to track the underlying library
dependencies. 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)).
>
> > 2) I get the feeling that you've started with the base packages
without
> > dependencies. For example, specifically disabling ncurses and such.
Do
> > you envision putting these dependencies back in? I suppose this
really
> > gets to the philosophy of making everything so vanilla that it works
on
> > all platforms. I think something is lost when this happens.
>
> I think I still do not understand your question correctly. What do you
> mean
> with "the base packages"? We have not taken over base packages (or any
> code at
> all) from any other RPM-based distribution. We created the bootstrap
> package
> and then from scratch all other packages.
>
> 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
>
> > 3) RPM macros that are really nice. Have you thought about
> > incorporating Mandrake/RedHat things like %_install_info and such
into
> > your spec files so that the distribution starts to feel like a
coherent
> > whole rather than a bunch of individual packages Also stuff like
> > breaking up the RPM binaries into somepkg and somepkg-devel RPMs?
>
> The usage of fancy RedHat macros we generally try to avoid for
> stand-alone and independence issues. Instead of the %_install_info
> macro I personally would at least use a wrapper macro
%{l_install_info}
> in order to being able to replace the stuff later without having to
> change any .spec files. Nevertheless using such addon features is a
> good suggestion. But if you look at our .spec files in detail you will
> recognize that they are _very_ concise due to our set of %{l_xxx}
macros
> and rpmtool, etc. That's our general goal: to have very compact and
> concise .spec files without any redundancy and kludges. And if we have
> to add a few extra macros to fulfill this goal even more we're happy
to
> use them.
>
> The breaking of packages into parts we already did but removed it a
few
> weeks before the OpenPKG 1.0 release. Because this is a very complex
> issue because of many side-effects and special cases. But adding this
> again is on our todo-list.
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.
>
> > 4) KDE & GNOME! These are really the biggies for us as I think
having a
> > KDE/GNOME environment makes things better for our users who are
> > accustomed to Windows, not CDE. Do you plan on adding this support?
I
> > don't mind porting existing RPMs to your spec file standards.
>
> Yes, I already started X11-based packages like Mozilla and Gimp.
> KDE we certainly will add later, too. GNOME can follow also.
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).
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
>
> > 5) Why no %changelog? It's great to scan through a Mandrake/RedHat
spec
> > file and see what changed so that you can incorporate that into your
own
> > RPM.
>
> OpenPKG is in CVS and there we have better logging and don't want to
have
> logs
> in two places. Perhaps we can use the auto-expand feature of CVS...
>
> > So the above are a bunch of things that I've tried to address in my
own
> > (CalPoly) distribution, and wonder what you think about these. I'd
love
> > not to reproduce effort that you've done and would be happy to offer
my
> > help. How can I get involved? What is your build lifecycle/team
> > structure like? How could I contribute new packages/package updates
> > (like enabling ncurses :)
>
> I'll write a webpage for www.openpkg.org on the details on how to
> contribute
> as a developer (CVS access, etc.). But until the contributor
environment
> is
> ready, just prepare your .spec files locally in send them to
> [EMAIL PROTECTED] for inclusion/discussion/etc.
>
> Ralf S. Engelschall
> [EMAIL PROTECTED]
> www.engelschall.com
> ______________________________________________________________________
> The OpenPKG Project www.openpkg.org
> Developer Communication List [EMAIL PROTECTED]
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [EMAIL PROTECTED]
