6100 subdirectories in /usr/ports/devel!
Dan Mahoney (Gushi)
freebsd at gushi.org
Mon Feb 19 16:29:30 UTC 2018
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
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
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".
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
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.
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
More information about the freebsd-ports