Date: Mon, 19 Feb 2018 08:25:09 -0800 (PST) From: "Dan Mahoney (Gushi)" <freebsd@gushi.org> To: blubee blubeeme <gurenchan@gmail.com> Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD ports list <freebsd-ports@freebsd.org> Subject: Re: 6100 subdirectories in /usr/ports/devel! Message-ID: <alpine.BSF.2.20.1802190823450.3676@prime.gushi.org> In-Reply-To: <CALM2mEkwX7Sym8=7gM1AJcbQEt=j622B12Z11SJG9NFSeh0_fg@mail.gmail.com> References: <20171228203634.GK99670@rancor.immure.com> <5A4557E8.70907@grosbein.net> <5A455A04.4090100@grosbein.net> <20171228211639.GL99670@rancor.immure.com> <c11f29e9-8ebd-1f66-f759-953882c191f8@freebsd.org> <CALH631=YvOB344o8EiiPz-LxyuuCgGif_NB%2BvYKe57w0VZ6O9w@mail.gmail.com> <CALM2mEkwX7Sym8=7gM1AJcbQEt=j622B12Z11SJG9NFSeh0_fg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ---------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1802190823450.3676>