Re: call for code audit help

[e.sammer]

Helge:

To start, thanks for the reply...

Helge Hess wrote:
> Hi,
>
> we also look into building a pkg management system for the GNUstep 
> environment. I had a quick look at your approach and it seems that you 
> are not basing your efforts on one of the existing pkg managers (eg rpm 
> or apt). May I ask why ?

This is *the* question I always get and not without good reason. There 
are some nice package managers out there. Without getting too deep into 
it (as it is off topic here) we didn't just write another wrapper around 
dpkg or rpm because there were some basic parts of the way the packages 
and system were built that just wouldn't really fit the standards of 
these package managers. We drafted a design spec and then stuck to it 
which meant we couldn't go with rpm - it didn't have the features and we 
couldn't go with dpkg / apt because to add the features we wanted that 
it didn't have (which were very few) would make it awkward. For this 
project, we needed to make sure we had exactly what we wanted and (for 
now) that meant a new package manager. The email I sent to the list 
wasn't meant to spark a package manager / ports / rpm / dpkg / linux / 
bsd war; I thought some people might want to take a look at the code and 
offer up some suggestions.

> Currently I tend to use rpm as the basis since it can manage multiple 
> databases on a single host, runs on multiple platforms, it is well 
> supported, quiet fast and - already provides a C library to process the 
> pkgs. So I would try to build an ObjC wrapper around that library (has 
> anybody done that before or wants to do this ?).

I thought a lot about doing this, but honestly, rpm has a bit of feature 
bloat, in my opinion and it tends to make it more complex than it's 
worth. I've been running SuSE for the last 5 years or so and the only 
time I actually use rpm is during a new system install (after which I 
just compile from source - it's easier most of the time).

> What's also missing for rpm is the "red-carpet" functionality which I 
> definitly want to have.

Very very true. Debian, by *far*, has the best package manager in my 
opinion and lspm was modeled after dpkg / apt in many ways. For our 
purposes, we wanted something a bit different in implementation yet 
similar in concept. Since many of the packages themselves would have to 
be rebuilt for LinuxSTEP, by using an existing package manager we ran a 
very high risk of people using a Debian package on a LinuxSTEP system 
(something that could prove catastrophic in some cases). Lspm now has a 
lot of the "red carpet" functionality (supports dependencies ala apt-get 
and remote fetching from mirror sites all automagically) in the LSCore 
framework making integrating package management into GS (or OPENSTEP / 
MOSX) applications very easy. Lspm is really just a class cluster in the 
LSCore framework - these classes are just "put together" to form the 
basic command line tool.

Again, I'm sorry this got off topic. The original purpose was to give 
the people who say "Where can I start?" or "How can I learn?" a place 
and project to check out. Of course, taking advantage of the development 
experience on this list also crossed my mind. ;)

Thanks again to all...
--
eric sammer <eric@linuxstep.org>
LinuxSTEP   <http://www.linuxstep.org>
InterfaceWM <http://interfacewm.sourceforge.net>