Date: Wed, 05 Nov 2014 16:01:30 -0800 From: Jeffrey Bouquet <jeffreybouquet@yahoo.com> To: Mark Felder <feld@FreeBSD.org>, freebsd-ports@freebsd.org Subject: Re: Reducing the size of the ports tree (brainstorm v2) Message-ID: <545ABA5A.2040105@yahoo.com> In-Reply-To: <1415223045.3436045.187536433.49F9A27E@webmail.messagingengine.com> References: <mailman.1.1415188800.63945.freebsd-ports@freebsd.org> <20141105162003.EFA3A6F0@hub.freebsd.org> <1415223045.3436045.187536433.49F9A27E@webmail.messagingengine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/05/14 13:30, Mark Felder wrote: > > On Wed, Nov 5, 2014, at 10:16, Roger Marquis wrote: >> Was a time when FreeBSD was believed to be a more stable and compatible >> platform than Linux. Of course all that backwards compatibility was >> thrown out the window with this year's make and pkg updates, which made >> management at my business much more receptive to the linux admin's calls >> for linux-everywhere, but this is a matter for the community to decide. >> > FreeBSD spent 20 years not changing and you know what we got for it? An > ugly mess. Please keep in mind that nobody is changing the core OS. > They're simply bringing our package mangement from the 1990s to the > 2000s, and hopefully after that dust settles we can move to the 2010s. > Yes, through this transition it's painful if you are used to never > having to touch your custom ports. The change important and the benefits > are far-reaching. You are grouping two distinct changes together, and disparaging, non-specifically, the old ports (package) system which served here, well, 2004 January to the present day. I sent another email, detailing in which, many > one files in the ports tree may be a bad idea. Having transitioned to pkg successfully on one machine, that I can still not upgrade pkg > pkg without hacks, and halfway on another, on which pkg2ng did not work, and is sort of in limbo ( an inaccurate pkg database, and buggy operation of a few pkg commands, and out of the blue segmentation faults ) I see pkg as more convenient BUT less reliable. Specifically here, An ugly mess.... not 1990s 2000s .... not reliable enough yet benefits far-reaching .... maybe in the future. Saving time here but with uncertainty. > > I don't care how good of a FreeBSD admin anyone is. You can't tell me > you won't find any of the following instances on your servers before > pkgng: > > - duplicate packages registered in pkg_info I could simply /bin/rm -rf the duplicate subdirectory. > - leftover files *everywhere*. find /usr/local -type f -print0 | xargs > -0 -n50 pkg_which | grep "not found" A small price to pay for stability. And what if pkg which (sqlite) is more prone to breakage, obsolete libraries, wrong compiler >> libmap... vs pkg_which which could be resurrected as a backup... I hope continually > - broken binaries discovered via pkg_libchk One can easily have that now, pkg upgrading to ruby20 default when ruby19 is still installed or something... or my limited experience is not the norm > > This is disgusting. You might as well just be extracting tarballs and > not using a package manager because the only benefit you're gaining from > the old ports tree is the automation of *building* and *installing*. Portmaster handily handled the switches -d -B -P -i -g (ports unless packages upstream) Why disparage that? Pure packages is not for everyone, and that in itself AFAIK is a feature not a bug of FreeBSD... > > Here's the lifecycle of a typical pre-pkgng server: > > 1) Install FreeBSD > 2) Install your ports/packages > 3) Server is in production > 4) Attempt to update ports/packages > 5) Disaster is now waiting to happen 3a... Production? update on a second machine, roll out to the main one. No disaster. Less preplanning or experience, and your scenario may be right, but numerous blogs of administering servers I've read over the years, and in FreeBSD books, paint an easier and more seamless sequence of events with each upgrade, most of each not being abstracted away from the command line, but line-by-line expertly managed. > Every time you need to update you might as well rm -rf /usr/local and > start over. I upgraded 5 > 5 > 5 > 6 > 7 > 8 > 9 and instances within each one, losing mutiple hard drives, but files in /usr/local still exist from 2004... > Some ports even barfed all over the base system, so > reinstalling wouldn't be a bad idea either. I read reinstalling not a bad idea, but only in the problematic case. > In fact, that was often the > solution where I used to work -- wait until a serious enough > vulnerability is affecting the server and then reinstall from scratch > with the latest RELEASE. > >> For most of us end-users it doesn't matter as we use portsnap >> (and update speed really isn't an issue). >> > The goal is to make pkg the norm and ports the very rare exception. Why 'very rare? ' I always thought that they were to work in tandem. Isn't tweaking of ports on one's machine consistent with knowing the ins and outs of all the ports as well as package workings? Make targets? etc. > This > will increase consistency, lower false bug reports, and greatly > ease/increase adoption by lowering the barriers But "this" here you have included both pkg (not yet seamless or as reliable in my opinion) and the new scheme of abstracting away the information in the smaller files. I see more bug reports from pkg (from here for instance)... It seems to early to call the above as a certainty. Apologies if I am sounding way critical upon wishing to simply advocate caution on any divergence from the reliability the ports tree and legacy package served for years upon years. While pkg is saving time here, it has raised new fears about the validity of my recommendations of using pkg/ports to others... not having any poudriere experience, not knowing how many low-powered routers pkg may not work on, having disks that may not upgrade well with pkg2ng if ever... other unanswered questions. > and raising the sanity > of a FreeBSD server over its lifecycle. > > -2c > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?545ABA5A.2040105>