gem, pip et al vs. pkg

[Matthew Seaman]

On 07/06/2016 18:21, Mikhail T. wrote:
> 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.

Perl packages aren't normally signed either.  However in all these cases
I believe you can get a package checksum from an HTTPS site
authenticated by certificate, which is at least better than nothing.

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

There's no technical reason why this couldn't be done.  The lack is more
down to no-one taking up the reins and pushing the project through.  It
used to be done for perl under the old packaging system -- remember
BSDPAN?  However there are a number of implementation niceties which
never could be handled with the old pkg_tools:

  * There was a hard-wired requirement to be able map packages onto a
    path in the ports tree.  This is no longer a big deal with pkg(8),
    and it may even be feasible to supply eg. an arbitrary URL as a
    package origin.

  * Recognizing that eg. a ported perl module and a module from CPAN
    (mutatis mutandis for other languages) are interchangeable.

  * Coping with dependencies other than additional modules from the
    same language.  The ports handles this: most language specific / OS
    agnostic package collections do not.  Functionally that means that
    modules with external dependencies should always be added to and
    installed from the ports.

  * Knowing how to detect the availability of updates for each of these
    different language specific modules.

Ports doesn't at the moment have a sufficiently flexible means of
specifying exactly what dependency versions could be used.  For instance
you can't say 'any version 1.2.x greater than 1.2.2 except for version
1.2.13 or else any version from 1.3.0 -- 1.3.x'

There's more than just the three languages you mention which could
benefit from this sort of treatment.  Don't forget PHP/Pear modules;
npm; and, not least, the granddaddy of all archive networks: TeX.

	Cheers,

	Matthew



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-pkg/attachments/20160607/a9bfc15a/attachment.sig>