Re: Status

[pancake]

>    BeeBS is just GSC, but it aims to be lighter, portable and easy to
>    maintain and track compilation problems.
> 
> Could you show some examples of where GSC isn't `lighter, portable,
> and easier to maintain' than pkgsrc?  It would help make GSC better.

lighter: is just a bundle of 30KB of shellscript. and 1GB of work space.
portable: it works on GNU/Linux and HURD, some BSD work done.
easier to maintain: maybe this is not the right "word"

GSC IMHO have a different aproach. It works nice, it fetchs the last
version of everything using gnuarch, so there's a lot of overhead. But
allows you to fix everything directly from the source.

BeeBS works with release tarballs, so it makes easier to "mark" some
versions as broken for the hurd, etc.

btw i don't wanna get this stupid discussion again O:)

> I atleast have a hard time seeing any of those problems, GSC is
> something like 10kb at its core, while pkgsrc's mk/ directory is 2.4
> megabytes.  On top of it, pkgsrc uses a make which isn't even
> available on GNU variants.  As for maintaining it, I haven't had any
> problems, it was done in a way to require minimal maintaining.

I was unable to use't on my GNU/Linux system, i had problems with
some programs that doesn't implement some flags, so imho GSC is nice,
but I liked to create another way to do a crosscompile for the Hurd.
And GSC doesn't crosscompile from scratch a GNU/HURD system afaik.

> I'd love to hear what you consider `heavy, unportable, and hard to
> maintain' in GSC.

GSC only works on GNU systems. right? so, is unportable. About the
"hard to maintain" I tell't before that i've used the wrong word.

BTW forget this discussion. It's pointless and senseless. I like GSC,
but GSC != BEEBS, so each software do what it must do. IMHO is not
dup-work, but maybe I'm wrong. So I used beebs to understand and learn
about the HURD.

>    > How is STUT different from GSC/stowfs?
> 
>    STUT implements the stow functionality into a transparent layer
>    that allows to use't on non-hurd systems (ln's) or in hurd (not yet
>    implemented, so, stowfs is not yet finished)
> 
> Personally, I don't see why one should bother with non-Hurd systems
> here, our goal is after all GNU and supporting non-Hurd systems only
> requires more effort from us.

I know, but compile a hurd in a hurd is a long-time task. So I was
using beebs on a dualxeon+hiperthreading 2.6GHz and 8GB of ram with
Gentoo GNU/Linux. The speed that this box gives me allowed me to stay
in front of the terminal instead of going out to get some beer and wait
some days for the build. It was just a practical solution. To get a
compiler farm of software for the GNU.

BTW i've no longer access to this box nowadays.

> I might be misreading something if so I apologise, but are you having
> plans on writting a new stowfs?

nope.

>    > Is there a possibility of merging the projects together?
> 
>    Of course. Stut if free to use and abuse.
> 
> That is merging programs, I was talking about merging projects, so we
> don't duplicate work.

About others packaging systems I was reading something abour corary and
looks really nice. But i've not tested yet.

--pancake