Re: Package management [was Re: A wishlist for a "Ruby Standard Library"]

* Robert Klemme <[e-mail]> [030508 00:42]:
> 
> "Rasputin" <[e-mail]> schrieb im Newsbeitrag
> news:[e-mail]...
> > I think I mentioned this once before, but the BSD package system
> > approach is simple and elegant, I think.
> 
> >From what you write below ("a dozen makefiles") doesn't necessary sound
> simple to me.  Some notes below.

<shrugs/>depends how well you know make, I guess. Can't say I'm a guru,
but my point is the complexity is in the system, not
the individual packages - I've written a package for rexml without
understanding too much of the setup in an hour, and most of that was
generating the list of files it installed.

s/makefiles/metadata/ before proceeding - I'm sure there's a better way.
 
> > pros:
> > -  no central site, so traffic is spread evenly around the site
> > - no need for people to use proprietary formats
> > - the system can figure out what platform (and even OS - see
> > bootstrap-pkgsrc project) it is running on, there's no need for
> > 1 package per platform as with precompiled packages)
> > - frankly, anything make can do, ruby could do standing on its head.
> >
> > cons:
> > - if you build this into ruby, how do you handle cases where you
> > install a ruby module that requires a native library? (This isn't
> > a failing in pkgsrc, but needs considering).
> 
> Precompile shared libs could be provided at a package's source site.

<nod> NetBSD does this - precompiled packages are available on the
CD and website - but it's a maintenance nightmare (that's 50-odd
hardware platforms for you) . Still, that's binary packages for you.

> > - you need to find a way to update pkgsrc
> > Probably more in the Ruby-specific case, I don't know.
> >
> > Updating on NetBSD is done via CVS, but there's no reason why each
> > package couldn't load its config from a website rather than a directory.
> 
> I think online update is not always feasible.  There should at least be
> the option of a offline update from CD or whatever.

True, but then you need to get ruby from somewhere! The system above
saves the source tarfiles into pkgsrc/distfiles/, and that can be
distributed on CD (with the exception of commercial or restrictively
licensed code, which can be automatically excluded if flagged as such in
its Makefile).
 
> > If the functionality was built into a small base distribution of ruby, I
> > don't see why it couldn't even grab modules at runtime if a require
> > failed.
> 
> Again, not every host is always connected to the web.

Hmm, think I got a bit carried away (don't know if ruby dynamically
requries files or not) - then again, if you're not on the net, the
auto-require fails and you're no worse off than you were before.

If the package system can't get a distfile, it stops with a message
asking the user to arrange for 'program-1.3.xx.tgz' to be placed into
pkgsrc/distfiles manually before retrying.
[ For some things <cough>Java SDK<cough>, the package can't be downloaded
automatically because the user has to click 'I ACCEPT' on some form
somewhere for legal reasons. ]
 
> > Sorry this is off-topic, I just wanted to point out alternatives to CPAN
> > we might want to emulate. I'm not on commission from NetBSD or anything,
> > if you want to use another system feel free (can I vote for BSD license
> > not GPL though) that's fine with me.
> 
> I don't think it's off topic.  Apparently this issue ponders around for a
> while and awaits its resolution.

I'm sure everyone has a favourite packaging system to model ruby's on,
so you end up in a 'bikeshed discussion'.  Now you know mine <g>

If anyone needs me I'll be lurking over there.

-- 
Rasputin :: Jack of All Trades - Master of Nuns