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.
> 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?
> 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.
> 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.
> 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]
