[RULE] uClibc versus glibc and packaging

[Michael Fratoni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 20 January 2003 06:48 pm, M. Fioretti wrote:
> On Mon, Jan 20, 2003 18:09:40 at 06:09:40PM -0500, Fratoni Michael 

First, sorry for the delay. I actually answered this several days ago, but 
kmail crashed in spectacular fashion while sending the message. Sent the 
load average up to the high 40's and began eating up memory. I'm not at 
all sure just how high it finally went. I couldn't get the machine back 
under control until it finally ran out of memory and began killing of 
processes. Of course, the result was the mail was lost, and I wasn't in 
the mood to start over. ;)

> > Doing this has been an interesting learning experience, though I
> > don't know that it has much real world usefulness.
>
> I think that it could have more than you seem to imagine. Yes,
> probably it is impossible to build a fully functional desktop (in the
> RULE sense of the world, i.e. all meat, no eye candy) without using
> both libraries, but *if* they can coexist, and the leanest ones makes
> leaner and faster, for example, 80% of programs, this still means that
> you can fit more stuff in less disk space and RAM and use it
> simultaneously, doesn't it? Or am I missing something obvious? If yes,
> please explain without embarassing me too much...

Oh, I can imagine quite a lot. The problem comes, as you guessed, from a 
maintenance standpoint. My goal was to see how many of the Red Hat stock 
rpms I could compile against uClibc, either without modification, or with 
just minor modification. I was trying to avoid having to create my own 
packages from source tar archives.

> Frankly, the part that worries me more in this context is maintenance,
> and if 3rd party RPMs would continue to be useable in a RULE system.

With just uClibc, 3rd party applications would be out of the question. 
They would have to be rebuilt and linked against uClibc. With both glibc 
and uClibc, well, I'd have to try a few experiments. ;)

> How much can you call Red Hat (technically, not legally of course)
> compatible something without glibc?

Not at all, really. uClibc is very useful, and an excellent project. It 
does lack a lot of functionality, however. For example, it lacks 
internationalization, although even that has begun to appear in CVS.
The drawback is that for each step closer to being a full featured 
replacement for glibc, the size increases.

> I'm not dismissing it, of course, all the contrary. It still makes a
> wonderful hack (man, I **must** get some sick days and start trowing
> out RPMs myself, once and for all...) and a definite life saver for a
> lot of hardware otherwise unusable. I am only noting that we should be
> prepared, at least in the long run, to the effort that this implies.
> Myself, I'll be really happy to learn how to do it step by step.

As I said, my goal for the test was an rpm and uClibc based install. 
Currently, this would require repackaging a _lot_ of rpms.
However, building from source against uClibc is fairly straight forward, 
and a good number of projects build with little effort. Even XFree86 can 
be built against it. My test machine now has many packages installed, 
some from rpm, but a lot from source as well. There is nothing wrong with 
building an entire machine from source, either. However, for an end user, 
that approach can be a nightmare for security and enhancement upgrades.

If anyone is interested in trying this, I'd be more than happy to explain 
how to go about building the root file system for the development 
platform.

- -- 
- -Michael

pgp key:  http://www.tuxfan.homeip.net:8080/gpgkey.txt
Red Hat Linux 7.{2,3}|8.0 in 8M of RAM: http://www.rule-project.org/
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+MhnJn/07WoAb/SsRAl42AJ9vIYI3VSgxK3wsR4ZaJI6eLg+bUACdFVte
zxDjVwTH5Z5iAdREOhD67J0=
=dv1e
-----END PGP SIGNATURE-----



_______________________________________________
Rule Project HOME PAGE:  http://www.rule-project.org/en/
Rule Development Site:   http://savannah.gnu.org/projects/rule/
Rule-list at nongnu.org
http://mail.nongnu.org/mailman/listinfo/rule-list