DragonFly BSD
DragonFly kernel List (threaded) for 2011-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: DragonFly versioning plan

From: Chris Turner <c.turner@xxxxxxxxxxxxxxxxxxx>
Date: Sat, 10 Sep 2011 23:11:43 -0500

On 09/10/11 20:28, Justin Sherrill wrote:
Here's the problems I'm trying to fix:

think it makes sense to separate the pkgsrc-tracking issues from the system-release issues as much as possible - these seem a bit bound up together in the proposal from what I can see

- I've been building pkgsrc quarterly releases for binaries, which is
fine, but it would also be nice to have pkgsrc-current reports to show
how much breakage there would be.

for really-long-term-release:

seems like the need for this was bound up with pkgsrc building troubles -
not sure why the ~6/mo cycle is a problem in-and-of-itself otherwise

unless I am mistaken?

yeah - I think the 'preview' stuff is pretty much unused though..

also - too much drift/delta between head and branches makes both bug MFC's
and pkg assuptions break, etc..

for the pkgsrc-branching-vs-df-release:

why not just 'only track whatever is latest stable pkgsrc at time of release' ?

this prevents the problems of needing 2x stable pkgsrc builds for a given release -
if people want new packages ... see 'for head-builds' below

for head-builds:

build 'latest current pkgsrc' and 'latest stable pkgsrc'

this isolates pkgsrc instability from git-tip DF users, but
still allows testing / showing 'what will break' in pkgsrc-head

having accidentally tried pkgsrc-head a few times I don't like the idea
of imposing either 'whatever is in pkgsrc head' or '2y old release' on
new/binary users.. personally I'll keep building my packages from stable though..

I don't think we care so much about paying attention / testing pkgsrc-current
vs latest-stable-release breakage - unless I'm mistaken.

the biggest issue imho is getting fixes upstream into pkgsrc and how that
ties into the pkgsrc relases - but I don't have to maintain the build setup :D
and I haven't tried too hard - simply maintained my own '/usr/pkgsrc/local' grab bag
which has long been on my todo list to get merged (aah life circumstances) - having
some kind of 'coordination effort' about this I think would help here but maybe
that's me being lazy and not getting involved with the pkgsrc people.. hmm

also - maybe moving / standardizing the pkg-build scripting in-tree would ease
administration of the builds? e.g. where it's pretty straightforward to reproduce
the 'official build' setup, etc more people can contribute / test / reproduce, etc.

I am admittedly not as involved with things these days as I'd like to be
so .. not sure of all the issues that relate w/r/t build setup .. but..
some 2c I suppose


- Chris

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