: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
<dil...@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.
