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

Re: My personal pkgsrc FAQ

From: Robert Luciani <rluciani@xxxxxxxxx>
Date: Thu, 18 Dec 2008 08:16:34 +0100

Justin C. Sherrill wrote:
> On Wed, December 17, 2008 6:26 pm, Robert Luciani wrote:
>> The second package set would be based on the current pkgsrc. I volunteer
>> for this task and am willing to spend the time to get it working
>> reliably and with updates in a timely fashion. The package set would
>> need to be rebuilt  _at least_ every other week, but hopefully more
>> than once a week depending on whether my machine can handle
>> bi-weekly updates. I'm going to set up a vkernel for this which
>> would just run all day, and try to get the process as automated as
>> possible.
> Using a vkernel may slow it down too much - not that vkernels impose a lot
> of overhead, but when the process already takes multiple days, even a
> small percentage increase may end up being a lot.

I'm thinking that in my case it will be alright since a complete build from
scratch takes between 4-5 days. Since I'm just building the updates all the
time, it shouldn't take more than a day (worst case) to get in sync.

The advantage of using a vkernel (or at least keeping your chroot around for a
long while) is that it allows you to keep rebuilding packages that were tagged
with vulnerabilities, from the same environment, for the entire lifespan of the
package set. Otherwise, security updates render a stable package set obsolete
very quickly. This was also why I mentioned pkg_chk and that it needs to be
fixed. Because now, updating packages is so arduous that people just leave
firefox-3 as an old version even though it might have multiple security problems.

I think if we want a stable binary package set with security updates, using
quarterly releases is the simplest choice. Then in conjunction, we have also
have the current package set for users that don't mind updating 10 additional
packages in order to satisfy new dependencies for some newly installed GTK app
that was built against the latest pkgsrc.

I think the versioning of the /All redirection is a fine idea if anyone wants to
implement it but since pkg_radd uses PKG_PATH we don't really _need_ to change
anything in the mirroring scripts except maybe agree on an "official" directory
layout. So a person wanting to use the current packages can just manually set
PKG_PATH to packages/current.

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