Date: Tue, 07 Jun 2016 18:21:12 -0400 From: "Mikhail T." <mi+oro@aldan.algebra.com> To: freebsd-ports@FreeBSD.org, pkg@FreeBSD.org Subject: gem, pip et al vs. pkg Message-ID: <a3bc5362-660f-80d5-c64d-f439052b259f@aldan.algebra.com>
next in thread | raw e-mail | index | archive | help
The ports tree has thousands of entries, which are simply thin wrappers around Ruby's gem or Perl's and/or Python's pip. Most of these ports conWhy do we need them? Obviously, it is primarily for other ports to be able to depend on them. But why can't we satisfy this need without creating a port for each such little package? If a port declares: RUN_DEPENDS= /foo/:gem//bar/[:/version/] why can't the /bar/-gem (with the latest or specified version) be automatically installed -- and/or registered as a dependency -- without there being a dedicated port for it? The biggest problem here is that neither Python's <https://www.davidfischer.name/2012/05/signing-and-verifying-python-packages-with-pgp/> nor Ruby's <http://guides.rubygems.org/security/> packages are normally /signed/ (not sure about Perl's), so simply downloading them is dangerous (not that this stops all people from using them anyway). But this can be side-stepped by us maintaining a checksum file of our own -- it would still be easier and more concise to maintain such a table with one row per package, instead of an entire port-directory with multiple files in it. In the other direction, if someone were to install a Ruby gem using the gem-utility (or pip-perl, or pip-python, or even rpm), why aren't the installed files registered in the pkg's database? We have the sources for all of these utilities -- we can modify them to register the package and its files with the pkg. The changes may even be welcomed upstream, if they are abstract enough to allow registration with the Operating System's package-manager on /all/ OSes, which would bother implementing a custom backend... -mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a3bc5362-660f-80d5-c64d-f439052b259f>