DragonFly users List (threaded) for 2008-03
Re: Pkgsrc problems [ was: lang/python24 build problems]
:> * Regular builds of pkgsrc HEAD on both our stable and HEAD with info=20
:> about failures made available for community. I think that many of us =
:> (including me) can take a look at logs and try to fix issues. The=20
:> important point is that we should try to catch as much of bugs as=20
:> possible _before_ release.
:Nice idea, except doing full bulk builds of pkgsrc does that its fair=20
:amount of time. If you have a multicore machine, you can run multiple=20
:builds in parallel on vkernels to make builds run faster, but even still =
:you need a beefy CPU, lots of RAM and not just a single disk, but a fast =
:disk array to power the build. SSDs would be ideal :).
This isn't a problem. We have pkgbox.dragonflybsd.org for that,
and Justin runs pkgsrc builds on it all the time.
It does take a while to do a full build... something like a week I
think. Right now pkgbox is a AMD 64 X2 3800+ (dual core) with 1GB of
ram. I happen to have a shuttle cube on my desk which I am using to
test HAMMER with a AMD 64 X2 5600+ (dual core) with 2GB of ram which
is approximately 20% faster.
:> * "Our man/men in pkgsrc" (sry, mr. Greene ;).
:We already have people who care enough about DragonFly on pkgsrc, but=20
:they're not enough, I agree; it's a lot of work to keep an eye on all=20
:packages, and staying focused on fixing issues instead of running into=20
:annoyances with pkgsrc all the time also requires dedication. If some=20
:people started flooding pkgsrc GNATS with patches for DragonFly, I'm=20
:sure commit bits won't take long to arrive.
:> There is at least one laternative as well of course - to branch pkgsrc =
:> (fork isn't correct term here IMHO). So, we could fix our issues in "ou=
:> pkgsrc stable", build our packages from this "branch" etc. While=20
:> recommended by some people, I personally don't like the idea much thoug=
:Like what happened to dfports? We don't have the manpower to maintain a=20
:respectable package repository ourselves.
:My opinion comes for free, but volunteering... I don't think I can=20
:commit the time to become an active pkgsrc developer :).
: Thomas E. Spanjaard
These are both options but I will note that it would not really be a
'branch' per say. What we would do is set up an automatic daily sync
from NetBSD to our pkgsrc CVS so we would always have the latest, but we
would also have the option of committing fixes into our tree to get
them off our table. We would use the cvs vendor import feature. Not
perfect, but still readily automateable.
I think it really comes down to what the particular DragonFly developers
who deal with pkgsrc regularly want to do.