On Mon, Feb 24, 2014 at 9:45 PM, Chris H <bsd-lists at bsdforge.com>
wrote:> Or perhaps GSOC proposal...
>
> Well, I just performed svn up across my entire server base, last night.
> For a planned major update across the farm, set for the following AM.
> This morning, I open /usr/ports/UPDATING to see what hurdles I might
> have to contend with.
> OMG! You have GOT to be kidding! REALLY! Not again...
> WAFM! OK I've been on BSD since day -1. I've got copies of the
original
> DEC tapes, and the entire history since. I loved everything about it. It
> was POSIX, it ultimately had ONE (smallish) steering committee. Which
> ultimately led to it's always being "stable", and
> trustworthy/dependable -- unlike the *NIX wannabe OS, that had HUNDREDS
> of "distro" makers. Making it more of an "adventure",
than server grade
> OS. Anyway, to the point; It was this dependability/reliability that
> kept me on the BSD train. I could ALWAYS depend on it, and I ALWAYS
> knew what to expect. THIS is what set it apart for me, and I'm QUITE
> sure, others. The philosophy/standard that BSD chose, allowed
> Administrators, and developers to adopt/create routines, and standards
> that catered to their environments, and to further hone their
> development maintenance environments to better suite their work, as well
> as to better contribute to the BSD community, at large. In short; it
> worked perfectly for everyone involved.
> In recent years, this has seemingly all begun to change; perhaps the
> first notable change was from the old-but-tried-and-true, csup/cvsup.
> That had permitted FreeBSD users/administrators to easily, quickly, and
> reliably update their source, and ports trees. But that method was
> dropped for subversion, on the basis that it was more flexible, and
> otherwise, more suitable. Unlike (c|v)sup, subversion has been plagued
> with security issues. Not to mention the enormous burden the change
> forced upon administrators, that had for years, developed systems
> surrounding the (c|v)sup method. To make matters worse; licensing
wasn't
> even in sync with BSD's licensing, let alone, under BSD development/
> management (standards?). There's the addition of clang -- a change of
> the make(1) framework. Maybe it's better, maybe it's not. Time
alone
> will tell.
> Speaking of; there's also pkg_, no... it's pkgng, or was it pkg. Or
how
> about WITH_, or was it SET_||UNSET_, or USE... ugh! It's all so hard to
> keep up with. Who-the-hell-knows anymore.
> Which brings me to my point;
> Is it just me? Or has FreeBSD become somewhat of a stranger, or Alien.
> Sure I get it; BSD is composed greatly of "contributors". Face
it. Those
> of us who spend the greater part of our lives, or free time coding,
> know; it can get really boring -- really boring. So who wouldn't want
to
> start cobbling on something new, and different?
> But FreeBSD ISN'T primarily a "hobby" OS, much like the other
*NIX-like
> OS(s) is/are. It is largely used by businesses, and those who's living
> DEPENDS on BSD. So this is my cry for a "sanity check";
> A proposal/RFC for a "standards committee" regarding the
path/direction(s)
> of the (Free)BSD ports system. I had the impression there already was
> one. But I've been wrong before. ;)
>
> How this goes is up to you -- those who(m) choose to respond.
> I would just merely like to address this matter. As I'm well aware that
> there are many who share to varying degrees, similar views -- even those
> whom are afraid, or unwilling to admit it. :)
>
> Please note, the preceding statements, are not vents of emotion, but
> binary acknowledgements based on my (and others expressed) experiences.
> This is NOT a flame. This is NOT a rant. It is an RFC. Nothing more,
> nothing less.
>
> Thank you for all your time, and consideration in these matters.
>
> Sincerely,
> Chris
>
I agree with many of your points, however, please take a few hours and
look at poudriere and pkgng.
poudriere is like tinderbox on steroids, it knows how to update its
ports tree, it works out when you change options what packages need to
be compiled, it can build packages easily and quickly for whatever set
of releases you are using, all from one box. I use poudriere at home
to provide packages (with my options set) for just one box, it is that
much better than using a ports tree directly. If you've got the RAM,
you can build each package entirely in a tmpfs.
A large port upgrade using ports used to take me an entire weekend,
even using clever tools like portmaster and/or portupgrade - poudriere
can produce the binary packages for my entire system, from scratch, in
about 4 hours.
The next bit is pkgng. Once you have these packages that poudriere has
built, each box simply needs a "pkg upgrade", and it's done. Set
your
jails up to run that during rc startup, and you simply need to
stop/start a jail to upgrade its packages.
Yes things have changed from the old way. The old way was a bit pants,
these new changes are *awesome* IMO - invest a few hours and I'm sure
you'll agree.
Cheers
Tom