6100 subdirectories in /usr/ports/devel!

[Dan Mahoney (Gushi)]

On Mon, 19 Feb 2018, blubee blubeeme wrote:

> I agree with this as well, why maintain these ports when they're being
> maintained upstream. Plus, if we do need patches, they can be applied
> during the build step.
>
>>>
>>> maybe with the ability to add some patches on the way through.. There is
>>> just too much going on there for us to follow properly.
>>
>>
>> I double this thought! This is what I'm goinf to head to with Haskell ports
>> one time.
>>
>> There is a hitch, though. Hackage, the haskell package database, is a dump.
>> You easily can get a version clash between to packages. No one curates
>> them. So, while there was only Hackage maintaining hs- ports made sense -
>> we've been cheking all the packages we have to compile/work together. But
>> now Stackage emerged, which is a curated package DB, so our ports is a
>> duplicated work now. The port is only needed if it is not present on
>> Stackage or if it require FreeBSD specific patches that haven't been
>> upstreamed yet.
>>
>> If PyPi and CPAN has the same notion of curated package set, we should not
>> duplicate this effort and remove much of our py- and p5- ports.

I'm going to speak only about perl here, but there's no reason that this 
advice couldn't apply to other languages.  I have some history, and some 
suggestions.

History:

CPAN distributes source, not binaries.  Ports delivers an instruction set 
to build binaries.  Some of the CPAN packages are written in C (for 
securtiy, speed, or linkability against other C/System libraries) and 
require compilation.

For those of us requiring a perl module on a bunch of machines, we don't 
have a good mechanism (outside of ports/pkg/poudriere) to build those 
modules and get them out.  One of the things pkgng lacks is the old ports 
"make pkg" function -- in order to build an installable package, you 
pretty much must be running poudriere.

Several of the CPAN modules currently around today don't compile cleanly 
under FreeBSD, but nobody cares because they just use the package which 
has the additional patches.

A few years ago, under pkg-classic, we had this thing called BSDPAN, which 
meant that if you installed a perl module using perl -MCPAN -e 'install 
Bundle::CPAN' those installations would get added in a pseudo-fashion to 
the pkg database.  This doesn't exist anymore.

I use pkg because I don't want to build perl, python, and libx11 from 
scratch so I can run a webserver.  On the same note, I use FreeBSD perl 
packages because I don't feel like chasing the endless CPAN dependency 
chain, which may or may not fail eight levels deep and stopping my build.

I'd love to know how you propose to solve the above before deciding that 
all the people who use Perl and Python ports consider the (mostly working) 
ports to be "someone else's problem".

Suggestions:

What I might suggest is that we split off the ports tree such that you can 
optionally not fetch portions of it -- for example, throwing a warning 
that you need the perl modules if trying to build a port with uses_perl5. 
Right now, that's not how the ports are arranged -- as an example, right 
now p5-Net-SSLEAY is under ports/security, not ports/perl5/security.

>From there, you might maintain a whitelist of perl ports which build 
exactly with only a standard set of arguments (i.e. setting Prefix, etc), 
so that you can, in needing perl ports, just *use* the standard perl build 
tools, instead of a skeleton port for each.

You might still need to have perl ports that require more "surgery" to 
work right, or CPAN modules for which the maintainer has gone away or 
retired (it's perl, after all), but it's a reduced subset which would be 
easlier to maintain/fetch/update.

You might bring back BSDPAN in some form or another -- how exactly it 
would work depends on what happens with this in the future, so that perl 
things installed from pkg, and those built from CPAN don't conflict.

We could make it so the build system knows how to fetch on demand the 
"extra" trees it requires.

We could also go through the ports tree and see which perl modules are 
solely leaf nodes, and not required (optionally or directly) by any other 
ports, and move those to a different list or subtree -- in those cases, 
the only stakeholder is someone writing code that directly requires that 
module -- you won't cause a cascading build breakage if that port vanishes 
or fails.

A lot of this feels like it wants to wait for the pkg system to support 
"flavors" so we can turn off the language specific options.

-Dan

-- 

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---------------------------