DragonFly users List (threaded) for 2008-03
DragonFly BSD
DragonFly users List (threaded) for 2008-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Pkgsrc problems [ was: lang/python24 build problems]


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 26 Mar 2008 11:30:30 -0700 (PDT)

:> * 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=
:r=20
:> pkgsrc stable", build our packages from this "branch" etc. While=20
:> recommended by some people, I personally don't like the idea much thoug=
:h.
:
: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 :).
:--=20
:	Thomas E. Spanjaard
:	tgen@netphreax.net
:	tgen@deepbone.net

    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.

						-Matt




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]