From owner-freebsd-stable@FreeBSD.ORG Wed Sep 3 13:57:53 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A9638C5 for ; Wed, 3 Sep 2014 13:57:53 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E8C211C60 for ; Wed, 3 Sep 2014 13:57:52 +0000 (UTC) Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 3C4B3427; Wed, 3 Sep 2014 09:57:51 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [HEADSUP] pkg(8) is now the only package management tool From: Paul Mather In-Reply-To: <540711FF.3050409@sorbs.net> Date: Wed, 3 Sep 2014 09:57:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <47F4AAAA-2D88-4F03-8602-880C4B129305@gromit.dlib.vt.edu> References: <20140901195520.GB77917@ivaldir.etoilebsd.net> <54050D07.4010404@sorbs.net> <540522A3.9050506@sorbs.net> <54052891.5000104@my.hennepintech.edu> <54052DFA.4030808@freebsd.org> <54053372.6020009@my.hennepintech.edu> <5405890F.8080804@freebsd.org> <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> <358B9E99-5E02-47BA-9E30-045986150966@gromit.dlib.vt.edu> <540711FF.3050409@sorbs.net> To: Michelle Sullivan X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-stable , Daniel Kalchev X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 13:57:53 -0000 On Sep 3, 2014, at 9:05 AM, Michelle Sullivan = wrote: > Paul Mather wrote: >> On Sep 3, 2014, at 8:28 AM, Daniel Braniss = wrote: >>=20 >>=20 >>> On Sep 3, 2014, at 1:40 PM, Daniel Kalchev wrote: >>>=20 >>>=20 >>>> On 03.09.14 13:28, Michelle Sullivan wrote: >>>>=20 >>>>>> We will have to live with it. WhateverHat is not better. >>>>>>=20 >>>>> I can't comment on that - the entire org runs *Hat, I've spent the = last >>>>> 3 years showing the benefits of *BSD and now I feel completely = betrayed >>>>> because there is no chance of them changing, "You see it's not an >>>>> Enterprise OS"... >>>>>=20 >>>> FreeBSD is a toolkit, not a "product" (ok, it's a product if you = look for toolkit). It is an very good toolkit to build UNIX-like systems = and many enterprises use it. Some do wonders with it, some, disasters. = As with any good toolkit, there is an entire ecosystem for support built = around it. FreeBSD also works out of the box but we are clearly not = discussing this here. >>>>=20 >>>> I understand your effort and frustration -- everyone who has dealt = with BSD UNIX has come to face it -- the media was instructed to = praise/blame Linux (out of topic why) and the mainstream "me too" crowd = is embracing it easier.. When most of the people who come to interviews = answer "I know Windows or Linux" your management does not have much = choice. >>>> Back in their days of glory, Cisco had very interesting marketing = strategy: "Never compete with anyone head to head -- the other party can = always optimize for the bench case. Instead, work with the user to build = and list of their requirements... and at the end see your product is the = only one that matches". Helps :) >>>>=20 >>> hi all, >>> sorry to barge in :-), but since I have been trying to upgrade my = /usr/local now for a few days,=20 >>> and counting, I tend to understand Michelle=92s frustration, I also = understand that managing a ports >>> distribution is not for the weak hearted.=20 >>>=20 >>> Here is my story: >>> before I updated the ports via portsnap, I made sure the tree was = clean, i.e., ran=20 >>> pkg check -Ba >>> and >>> portmaster -dvga >>> and all was ok. >>>=20 >>> upgraded ports, ran portmaster ports-mgmt/pkg, >>> and now, since that day I am running >>> portmaster -dvga >>> and hand fixing issues. >>>=20 >>> all this in a non production environment - learned from past = experiences. >>> btw, we have several hundred computers, most of them desktops = running Linux, but >>> all the servers run FreeBSD. >>>=20 >>> Basically, I dread the day I run portsnap fetch update >>>=20 >>=20 >> Fairly recently, there was launched a "stable" ports branch. This is=20= >> updated quarterly, and seems akin to the quarterly releases of pkgsrc=20= >> in that the given branch receives only security updates after it is=20= >> created. It appears to be fairly low-key. I remember seeing an=20 >> announcement on several FreeBSD mailing lists about its initial=20 >> release, but haven't seen anything since (even though I believe it is=20= >> now in its second quarter, at least). >>=20 >> My question is this: does anyone have experience of tracking ports = via=20 >> these branches? Does it work well? I can see that it would be=20 >> advantageous to those wanting less frequent churn. I wonder, though,=20= >> whether it doesn't just postpone the headaches to a quarterly basis,=20= >> when the next branch is made. It would seem that all the churn would=20= >> come all at once. Some people recommend not going too long between=20= >> ports updates because there's an increasing probability something = will=20 >> fail to update the longer you wait. Is a quarter just right in terms=20= >> of time? >>=20 >> I don't believe the "stable" ports branches are completely like the=20= >> pkgsrc quarterly releases. As far as I know, the pkgsrc quarterly=20 >> releases are a chosen subset of the regular pkgsrc rolling release=20 >> version, whereas the "stable" ports branch is a snapshot of ports at = a=20 >> given time. I don't know what measures are taken to ensure that one=20= >> version of the "stable" ports branch can upgrade to the next "stable"=20= >> ports branch. Is it left as an exercise for the reader to pore = through=20 >> /usr/ports/UPDATING and work out what is needed to be fixed by hand? >>=20 >> This is not intended to be a slight on the "stable" ports branches. = I=20 >> just want to solicit feedback from people who have actually been = using=20 >> it, to determine how successfully it works in practice. >>=20 >=20 > One would expect OS tools such as portsnap to give 'stable' or = 'release' > not 'bleeding edge'.. considering it's listed as the recommended way = to > update... As I pointed out, until fairly recently there was no such thing as a=20 "stable" release of the ports tree (it's traditionally been a rolling=20 release model, like -CURRENT). My question was to those who have been=20= using the "stable" branches: does it make managing ports updates=20 easier, or does it just concentrate all the problems into the=20 transition period between one quarterly branch to another? I've been=20 contemplating switching to the quarterly branches for production=20 machines, so would appreciate feedback. Portsnap doesn't have any concept of tracking branches, so far as I=20 know. It would be nice to have that feature now that there are the=20 "stable" ports branches. I guess if you want to track "release" via portsnap the answer is not=20 to run portsnap. :-) (A "release" ports tree never changes, so why would you need portsnap=20 to track its changes, unless you're talking about updating ports from=20 one -RELEASE to another, like freebsd-update does for the rest of the=20 OS?) The designated tool for tracking branches is now Subversion. I believe=20= that's why they added svnlite in 10.x. Cheers, Paul.