Date: Thu, 11 Feb 2016 21:21:41 -0900 From: Royce Williams <royce@tycho.org> To: John Marino <freebsdml@marino.st> Cc: Kevin Oberman <rkoberman@gmail.com>, lev@freebsd.org, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: Removing documentation Message-ID: <CA%2BE3k91S=wcz_gfNhA8uHPETeVnFixGTUX4w=tSzkY5XqHAM8w@mail.gmail.com> In-Reply-To: <56BD2A1E.1020706@marino.st> 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> <56BD2A1E.1020706@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 11, 2016 at 3:41 PM, John Marino <freebsdml@marino.st> wrote: > > On 2/12/2016 1:22 AM, 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 not a linux guy so those things don't mean much the me. The > abstraction layer here is at the appropriate level. I'm not seeing this > fragmentation problem you're talking about, at least not with the newer > tools. It's the long tail of non-newer tools that appears to be a big part of the problem. I think that you and I are in agreement there. But I also think that the older tools do some things well that enough people will miss that it will undermine adoption of newer tools for a while. > > > 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. > > Why do you think this is the case? Ports defines the dependencies and > pkg respects them. I'm not seeing where there more than one method > here. What other ones are there? The current ports/pkg relationship is still fragile, perhaps because it's new. I almost abandoned FreeBSD entirely a couple of months ago when an interesting corner case of the use of pkg managed to unilaterally and without warning delete in its entirety the contents of /usr/local/etc/rc.d in of my jails. Contrast this with the Ubuntu world, where there is a well-baked "unattended-upgrades" option that automatically downloads and upgrades all security updates for both the OS and all third-party packages. > > > 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. > > Synth exist because people are insisting to build from source (even > irrationally) so they might as well do it correctly. The statement > above doesn't have anything to do with Synth being a binary. If you believe that people who want to build from source are irrational, to me this means that you do not yet understand the current use cases of the software you're purporting to replace. > > If a shell script was so good, why is portmaster unmaintainable? I wasn't advocating for using a shell script. I'm advocating for a core-driven, Foundation-funded initiative to identify requirements and functionality for true, integrated ports and packages management, drive it to completion for parity with modern package management practices, and bring it into core. > > > 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. > > THERE'S NO REQUIREMENT THAT SOMETHING THAT BUILDS PORTS NEEDS THAT > ITSELF IS BUILT FROM PORTS. You responded to something different. Breathe. :) I'm not saying it's required. I'm saying that it's what many people do -- and probably for reasons that should be identified and understood before dismissing them. > > 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. > > Well, except *this* tool will never be in a "bootstrap" path. Above is > completely irrelevant. Besides, if the base is built, ports work, > period. There are no "compilation" requirements. > > > > 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. > > 1) you should focus on retiring the old tools No disagreement there. > > 2) It will never be part of base That's where we differ. I think that a software management suite that has fully identified the use cases would necessarily need to be part of base. And the fact that it's not part of base is only going to make the fragmentation worse over time. Mine is just one opinion, of course. > > 3) no ports tool has even been part of base I know. I think that's bad. > > 4) the "winner" will be determined by merit. If some people insist on > using inferior/broken/obsolete/unmaintained tools it's their choice and > problem. The majority will migrate naturally. I think that all previous attempts to solve the problem had the same idea. It hasn't happened yet, and my assertion is that it hasn't happened because the full suite of requirements for a unified solution are A) not yet well understood, and B) not sponsored at high enough levels by the project (read as: Foundation funding). > > This started because I think that if a tool is documented in handbook, > it must be maintained (not part of base). I've got no issue with > non-base software documented. I was saying that being in the handbook > should have a required level of quality and abandoning it would cause > the quality to fall under that level. I have no disagreement with this at all. I semi-hijacked this thread to try to solve what I see as the deeper problem. Synth is, in some ways, an innocent bystander. :) My soapbox is that I see most software-management-related FreeBSD projects (like portmaster, portupgrade, Synth, etc.) as noble heroics that are executed in a relative vacuum by well-meaning and gifted folks who try to solve the problem as best they can at the level they can. Software management needs endorsement and requirements gathering from some high-powered people from all branches of FreeBSD development and usage. I want more for FreeBSD than can be accomplished at the wildcat level. The closest equivalent I can think of is freebsd-update, which was a one-man job by a very smart and very motivated person who understood the problem space well, and who executed it well enough for it to become part of base ... but even then, has failure modes and fragility that should have been addressed before it became part of base (and that I think would have been caught if the requirements had been identified up front by a broader (and better-funded) team). freebsd-update is great, but it could be better -- and it's the kind of thing that's so fundamental to an operating system that "if you think it should be better, send us a patch" indicates a significant misunderstanding of its importance. I feel the same way about software management. We can drop the topic and move on to the mechanics of getting people familiar with Synth and answering specific objections to its use. I genuinely hope that it does well. Royce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BE3k91S=wcz_gfNhA8uHPETeVnFixGTUX4w=tSzkY5XqHAM8w>