Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Sep 2014 16:34:46 +0100
From:      Ben Morrow <ben@morrow.me.uk>
To:        paul@gromit.dlib.vt.edu, freebsd-stable@freebsd.org
Subject:   Re: 20XXQN ports branches [was: [HEADSUP] pkg(8) is now...]
Message-ID:  <20140904153442.GA2004@anubis.morrow.me.uk>
In-Reply-To: <358B9E99-5E02-47BA-9E30-045986150966@gromit.dlib.vt.edu>
References:  <5405890F.8080804@freebsd.org> <CAF-3MvNBWSEWF-HarwF0xcXQgo=7-dO%2BtvLMO1maELPY0RVhQQ@mail.gmail.com> <20140902125256.Horde.uv31ztwymThxUZ-OYPQoBw1@webmail.df.eu> <5405AE54.60809@sorbs.net> <1D2B4A91-E76C-43A0-BE75-D926357EF1AF@gmail.com> <5405E4F5.4090902@sorbs.net> <5406BD65.705@digsys.bg> <5406ED34.7090301@sorbs.net> <5406F00C.6090504@digsys.bg> <C4EC1A3A-6EB1-4EE1-ACEA-12C8E203991C@cs.huji.ac.il>

next in thread | previous in thread | raw e-mail | index | archive | help
Quoth Paul Mather <paul@gromit.dlib.vt.edu>:
> 
> Fairly recently, there was launched a "stable" ports branch.  This is 
> updated quarterly, and seems akin to the quarterly releases of pkgsrc 
> in that the given branch receives only security updates after it is 
> created.  It appears to be fairly low-key.  I remember seeing an 
> announcement on several FreeBSD mailing lists about its initial 
> release, but haven't seen anything since (even though I believe it is 
> now in its second quarter, at least).
> 
> My question is this: does anyone have experience of tracking ports via 
> these branches?  Does it work well?  I can see that it would be 
> advantageous to those wanting less frequent churn.  I wonder, though, 
> whether it doesn't just postpone the headaches to a quarterly basis, 
> when the next branch is made.  It would seem that all the churn would 
> come all at once.  Some people recommend not going too long between 
> ports updates because there's an increasing probability something will 
> fail to update the longer you wait.  Is a quarter just right in terms 
> of time?

I'm tracking these branches, though not in any sort of 'enterprise'
environment, just for a couple of servers and a couple of desktops. I
have to say it's a huge improvement, at least with the time I have to
dedicate to keeping things up-to-date: given the amount of general churn
in the ports tree at the moment, I had actually taken to keeping a local
stable branch of the tree in git, and cherry-picking specific ports as I
needed them. (The fact that I switched from portmaster to poudriere,
which insists on rebuilding everything that's changed, didn't help.)

Needless to say, this was a tiresome process: I had some scripts which
would take a port, find its deps, and try to cherry-pick what was
needed; but it often didn't work right, and I had to just bite the
bullet and merge the main ports tree in. (At which point I had lots of
merging fun to deal with.)

So, having someone else do this work, in a somewhat more organised
manner, is a big win for me :). (Thank you, bapt@ and everyone else
involved.) So far I've only gone through one rollover (Q2->Q3), and,
while it took a bit of effort to merge forward my local changes and
while I ended up rebuilding nearly everything, it was relatively
painless. Certainly a great deal easier than having to run around
chasing deps every time a security advisory came out.

One thing I'm not entirely clear about, though, is the policy about what
gets MFHed. I was expecting that any port with a current SA would be
updated (and nothing else would), but currently I have firefox-esr,
nginx-devel, serf and subversion showing advisories and they don't
appear to be going to be updated in 2014Q3. Firefox, in general, puzzles
me: I've had to backport FF updates several times because of advisories,
and yet Chromium (say) seems to get regular MFHs.

> I don't believe the "stable" ports branches are completely like the 
> pkgsrc quarterly releases.  As far as I know, the pkgsrc quarterly 
> releases are a chosen subset of the regular pkgsrc rolling release 
> version, whereas the "stable" ports branch is a snapshot of ports at a 
> given time.  I don't know what measures are taken to ensure that one 
> version of the "stable" ports branch can upgrade to the next "stable" 
> ports branch.  Is it left as an exercise for the reader to pore through 
> /usr/ports/UPDATING and work out what is needed to be fixed by hand?

I'm not quite sure what you mean here: yes, you still have to read
UPDATING whenever a port actually gets updated. The ports tree in
general goes to a lot of effort to make upgrades work in spite of
occasional upstream stupidity; when this can't be done automatically,
UPDATING is the only option. 

Ben




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140904153442.GA2004>