Removing documentation

[Jim Ohlstein]

Hello,

On 2/11/16 7:22 PM, Royce Williams wrote:
> On Thu, Feb 11, 2016 at 11:17 AM, John Marino <freebsdml at marino.st> wrote:
>> On 2/11/2016 9:08 PM, Royce Williams wrote:
>>> On Thu, Feb 11, 2016 at 10:33 AM, John Marino <freebsdml at marino.st> wrote:
>>>>
>>>> On 2/11/2016 8:25 PM, Lev Serebryakov wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA512
>>>>>
>>>>> On 07.02.2016 17:28, John Marino wrote:
>>>>>
>>>>>> ports-mgmt/synth.  I would love to hear what signficant thing
>>>>>> portmaster can do that Synth can't.  (honestly)
>>>>>   Be installed FROM PORTS without all this build-one-more-gcc stuff.
>>>>> Ada? For *port*management* tool? Are you joking?
>>>>
>>>> Let me guess.  You've spent actually 0.0 nanoseconds preparing on the
>>>> subject before providing this enlightened take for the list.
>>>
>>>
>>> Having read the entire thread, separate from the relative merits of
>>> Synth, the core of Lev's incredulity isn't that off the mark.
>>>
>>> On the face of it, Synth requiring ncurses seems reasonable ... but
>>> its Ada dependency is a bit of a mild POLA violation.
>>>
>>> Don't get me wrong -- I actually think Ada is pretty cool, and Lev
>>> could have been nicer about it ;), but he's essentially right.
>>>
>>> People's instincts are that software management is core functionality,
>>> and should have few unusual dependencies.
>>>
>>> My earlier side-thread point stands.  FreeBSD software management is
>>> fragmented.  Until that is resolved, a lot of time and effort will be
>>> wasted treating the symptoms.
>>
>> Actually, you missed the fact that synth (nor poudriere) doesnt
>> re-invent anything.  Both are tightly integrated with pkg(8). You spoke
>> of both as if they were similar to portupgrade.
>>
>> The "wrapper situation" that you proposed is already here.  So the whole
>> "fragmented" thing is not really true.
>
> 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.

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...

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.

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...


>
>> 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.

-- 
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain