Re: DragonFly versioning plan

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:It is possible to build pkgsrc binaries with the previous release's
:tools.  You can't install binaries built with that newer release's
:pkg_install using the older pkg_install.  So if I put a newer set of
:binaries on avalon, pkg_radd won't work.
:...

:What's wrong with removing previous binary packages before installing
:new ones?  The fact that you're removing all the existing packages
:before you can install new ones.

    If we provide a pristine pkgsrc binary install for the quarterlies and
    for pkgsrc-current a person could 'reset' their base utilities for their
    binary packages and reinstall the rest from there.  It could all be
    wrapped up into a script which records a list of all primary packages
    currently installed, then goes through the deletion and recreation of
    /usr/pkg (keeping certain things like /usr/pkg/etc intact) for the new
    pkgsrc branch being requested.  Thus the base utility issue is also
    solved.

    This 'pristine' install from scratch is something we already generate
    when we are doing a pkgsrc bulk build, its the first thing we do before
    we start the bulk build process (building the bootstrap and a few selected
    additional utilities).  We'd just package that up as a separate entity
    that the user script can download separately, before moving on to the
    bulk build.

:We (especially me) are burning a lot of time, CPU, and disk space
:building binary packages, and the process resets every 6 months, where
:we go back to zero and rebuild.  I'd much rather continuously build
:for a platform that isn't changing, and for a platform that's
:following a constant change (pkgsrc-current) rather than 3-month
:changes from pkgsrc quarterlies mixed in with 6-month changes for
:DragonFly, that aren't on matching timetables.

    Definitely being able to avoid having to rebuild pkgsrc for each
    nominal -current release is a good thing.  That has held up the
    release process many times.

    Changing the stable release would be less onerous if binary
    compatibility is maintained (is that possible now?).  Someone
    on an older stable branch could be supported with an archived set
    of binary packages that we no longer maintain on new pkgsrc branches
    or with pkgsrc-current.  Those people would be on their own, or
    they could upgrade the a more recent stable to get fully supported
    binary packages.  Seems reasonable to me.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:Here's an example going on right now.  pkgsrc-2011Q1 is available as
:binaries now.  I built pkgsrc-2011Q2, but it can't be automatically
:installed by pkg_install because of the aforementioned restriction.
:(though I hope that will be fixed/mitigated soon.)  pkgsrc-2011Q3
:should be out by the end of the month, so I can restart the building
:process for that, but it takes weeks, and according to our schedule,
:DragonFly 2.12 is due soon, so the build would intersect with the new
:release, so I can either wait for it (so packages in binary form get
:farther out of date) or build on 2.10 and then again on 2.12, burning
:a lot of resources and creating a few gig of unused packages, or 2.12
:is delayed farther to give time for the build, so we're off the
:6-month schedule at that point anyway.