Date: Fri, 12 Feb 2016 06:38:19 -0900 From: Royce Williams <royce@tycho.org> To: Jim Ohlstein <jim@ohlste.in> Cc: John Marino <freebsdml@marino.st>, Kevin Oberman <rkoberman@gmail.com>, lev@freebsd.org, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: Removing documentation Message-ID: <CA%2BE3k924LhG-%2BD7V0T_D_Km7KrXJ%2B3fHkVdyPjS7gdkZcwd5Lg@mail.gmail.com> In-Reply-To: <56BDF2A3.9030100@ohlste.in> References: <56B754A8.3030605@marino.st> <56BCE01D.4010701@FreeBSD.org> <56BCE218.40403@marino.st> <CA%2BE3k93iYs1p5Je-AKwJ7pVLdzYgSXWqb4P0XoD0oTJhrkt==Q@mail.gmail.com> <56BCEC5F.4020007@marino.st> <CA%2BE3k930YfN=LADkE7X4a82RSPZ-MSeKkC=U_J8kKDiy6vot=w@mail.gmail.com> <56BDF2A3.9030100@ohlste.in>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 12, 2016 at 5:56 AM, Jim Ohlstein <jim@ohlste.in> wrote: > On 2/11/16 7:22 PM, Royce Williams wrote: >> Is the abstraction is happening at the equivalent level here? The >> platforms that I'm thinking of -- that appear to have already solved >> this entire class of problem long ago -- feature wrappers around >> apt-get, not wrappers around dpkg. >> >> I'm advocating that we stop quasi-providing four different flavors of >> apt-get. Until there is a single and official mechanism for both >> dependency resolution and configuration option management, the >> fragmentation remains. > > Sadly, I also use dpkg-based systems, not my first choice, but because > sometimes they're the best currently available tool for the job at hand. I'd > need about thirty hands to use my fingers to count how many times apt-get > has left me with a broken package system, though aptitude usually is able to > fix that. Most often that has happened after adding a third party repo (it > happened recently with using MariDB's own repo instead of the official > package) or when compiling from source and trying to delete unnecessary > cruft. The biggest drawback to those systems is that compiling software and > registering it can be a pain in the ass. The second biggest problem is those > systems (Debian and Ubuntu specifically) are built around users who are > totally willing to have the developers choose which options will be compiled > in to "official" and "non-official" repos. That is, people who compile their > own binaries are really an afterthought in the Debian and Ubuntu world. Some > might call that a strength, and yes, dpkg is a nice system for people who > want that kind of thing. It's made Debian based systems very popular, no > doubt about it. Third-party repos are an entirely other kettle of fish, I think. At that point, you're throwing yourself on the mercy of uncoordinated third-party dependency information that conflicts with the official one, and the dpkg/apt-get system should not be held responsible for that. > FreeBSD is different in that regard. The ports system is one of the things > that makes it great. Being able to choose whether to compile everything, > compile some ports and use official packages (or non-official repos) for > others, or entirely to use pre-built binaries is one of the great strengths > of FreeBSD and is one of the features that distinguishes it from most > flavors of GNU/Linux. There are even tools for creating repos fairly easily. > Have you ever tried to write a spec file for an RPM based distro? Ugh! > Unfortunately, dpkg is not designed for people in those first two categories > above. It can be made to work, but requires much more effort. Add in systemd > and the nightmare continues... Interestingly, my experience -- after having been an admin for 70+ FreeBSD boxes for a 50K+ ISP user base for 12 years -- is different. It is the apt-get system that has never failed me, and it is FreeBSD that has regularly left me with a software installation so wrecked that I had to deinstall every third party package and start over, or spending hours scripting a search-and-destroy mission to clean up the mess. When people with significant FreeBSD experience regularly recommend the "nuke it from orbit" remedy regularly to people in the forums, that's a sign that something is deeply wrong. My Linux/dpkg/apt-get experience is entirely different. I have pushed dpkg-based systems through three major OS/ABI upgrades with one or two commands, almost without having to perform any manual steps at all -- and when I did, someone had captured them as part of the package system, informed me about it up front in the release notes, and almost always empowered me to run a simple package command to do what needed to be done automatically. To be clear, this is not "hey, the default version of perl has changed, please do one of these five things, and if they don't work, delete everything and start over" /usr/ports/UPDATING equivalent. These were genuinely deep things that justifiably required a human to decide which way they wanted to go. And there was no ambiguity in the official documentation about which commands I needed to run -- because there was a single, official method included in the base OS. Managing software across FreeBSD OS upgrades, by contrast, is replete with manual software removal and reinstallation steps, hunting down old library dependencies, etc. Recurring "nuke it from orbit" debacles, coupled with the necessity of /usr/ports/UPDATING, makes the ports system an order of magnitude less reliable than stock Debian/Ubuntu ports. This upgrade/management friction makes me far less likely to want to try to upgrade a FreeBSD system, which, in turn, when faced with a new install of some kind, makes me far more likely to use and recommend Ubuntu server over FreeBSD. This pains me greatly, as I have been a FreeBSD advocate/fan for fifteen years, and I believe that FreeBSD's tightly integrated kernel/userland/docs has the potential to be far superior. In the meantime, we keep reinventing the wheel. And each time, /usr/ports/UPDATING survives. And each time, the list of possible software management tools grows, such that each of them has to be mentioned in /usr/ports/UPDATING. This is another sign that something is deeply wrong. Any software management solution that does not kill /usr/ports/UPDATING forever is insufficient. There are other deep requirements of a software management tool suite so compelling that it would make all others obsolete. Those requirements should gathered and sponsored in an official way, instead of being developed by heroes in a vacuum. > This discussion is aimed at people who prefer to compile at least some of > their own binaries, else they wouldn't need Portmaster or Synth or poudriere > or portupgrade. Really and truly, and with due respect, speaking about dpkg > is really a diversion, unintentional as it may be, and detracts from your > main point about a totally unified package/ports system, which you believe > belongs in base. I don't entirely disagree with that, but having choices > about what wraps around pkg(8) should be up to the user. I use poudriere. > For my purposes it's the best available tool. Even if you have half a dozen > jails on one box poudriere + pkg makes distributing binaries to those jails > a joy. Synth might do the same. Portmaster might be satisfactory for > building a small number of ports in a system that mostly uses official > packages. Portupgrade, if you can live with the ruby dependency and the > occasional risk that it will crap out when upgrading a dependency, still > works well for solitary systems using only ports. My point is that the main > tool is there. It's pkg(8). It does a _reasonably_ good job of sussing out > what's necessary, installing only run dependencies, and avoiding "dependency > hell". For people who use only official packages I'd daresay it's superior > to apt-get. Can it be improved? Yes. I have a wishlist in fact. However, > it's a young tool that really is excellent, especially compared to what was > (not) present previously. What tools, if any, a user chooses to employ > around pkg is up to that user. On Debian and Ubuntu I need both apt-* tools > and aptitude. On FreeBSD I currently use poudriere. Others only need pkg > itself. I have no disagreement with most of this. pkg is, indeed, a big move in the right direction. I do believe that the fact that different tools are needed for different types and counts of deployment is also a sign that something is wrong. > In my use case, I compile everything myself because I like to customize > options and there also may be a slight control issue there as well. ;) I use > poudriere and maintain different repos for different options. Just the other > day I spun up a new one for the yet to committed PHP 7.0 ports. It took a > couple of minutes to do, though compiling some of the modules was an effort > - separate issue. I created a jail, added that repo, installed php70, and > was ready to test. To do that on Debian would probably have been a lot more > effort, though I imagine someone has a repo out there with packages, if I > wanted to use someone else's packages... This is, indeed, a gap in the Debian world. It's one that the ports system is a great start towards resolving. That's why I think that ports + pkg could be a superior offering that people would flock to, and which deserves more focus. >>> Synth is a binary. There's no POLA there. >> >> If there were no ports system, and everything was package-driven, I'd >> agree. Synth and its cousins exist because people work from ports -- >> which means that dependencies matter. >> >>> There's no requirement to build from ports, that's an unsubstanciated >>> invention. Notice that not a single person could defend that position >>> after a challenge. There's no technical basis for it; it's just >>> emotional. >> >> The laissez-faire "there's no requirement to build from ports" that >> permeates FreeBSD is exactly what's wrong. The fact that half of the >> documentation and quasi-official tools tell people "hey, use one of >> these three ports management tools, or maybe packages, pick what works >> for you -- oh, and be sure to check /usr/ports/UPDATING every time you >> touch any port or package" is a deep symptom of this fragmentation. >> >>> In a straight fly-off against any of the tools, Synth wins hands down >>> with any objective measurement. Poudriere is slightly more bulletproof >>> and more appropriate for a cluster (as it was targetted at) but for >>> average user Synth is better suited. >>> >>> It's a concurrent builder. Ada is a concurrent language. How is its >>> suitability even a debate? >> >> Because FreeBSD software management itself is not purely package based. >> >> As long as the ports system exists (and I think it should!), the >> management of compilation requirements -- especially for something >> that might need to be bootstrapped early, like a software management >> tool -- is a valid topic. >> >> To be clear: except for the Ada/ruby/whatever dependency chain, my >> beef isn't with Synth qua Synth. It's that every time we spin up Yet >> Another Optional Software Management Tool, we fragment further. If >> Synth becomes the holy grail of package management -- so compelling >> that it becomes the only choice people would want to make, which is >> what I think we need -- then it should become part of base. >> >> If that happened, would we want to ship with Ada in base? If not, why >> not? > > This is a good point. I still don't understand why pkg(8) is not in the base > (though I imagine there's a reason and it takes less than a minute to > install). There can't be many users who install a base system and use it > without a single additional piece of software. However, for my $0.02, that > is the only change I'd make to base at this point with respect to package > management, aside from my pkg(8) wishlist. As an aside, and fwiw, unless > there is a non-GPL'd Ada compiler out there, we won't see Ada or any > Ada-based binaries in base, even if Synth turns out to be the best thing > since sliced bread. Agreed. And Matthew Seaman's point downthread that pkg is still young and could, indeed, end up in base one day is an important one. Jim, thanks for the thoughtful reply ... including the parts where we disagree! > "Never argue with a fool, onlookers may not be able to tell the difference." > - Mark Twain I'm sure this is how John's feeling about me right now. ;) Royce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BE3k924LhG-%2BD7V0T_D_Km7KrXJ%2B3fHkVdyPjS7gdkZcwd5Lg>