Gentoo Archives: gentoo-dev

From: anoteros@××××××.io
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Integrating Portage with other package managers
Date: Wed, 07 Mar 2018 16:06:51
Message-Id: a75fecad-5d48-b8ce-932e-faa97970c82b@teknik.io
1 Having used Gentoo for a few years now, one thing that has been annoying
2 to me is the tremendous duplication of effort and uphill battle of
3 creating ebuilds (build recipes) for language-specific packages that
4 already have their own build systems.
5
6 For example, many languages such as Python (pip), Node (npm), Ruby
7 (gems), TeXLive (tlmgr), Haskell (cabal), Rust (cargo) have ways of
8 redistributing up-to-date dependencies and ensuring that they build
9 properly in most environments. Portage, it seems, does not take
10 advantage of this at all. If I want to install the package 'foo', which
11 has 'bar' as a dependency (which has been installed through cabal, for
12 instance). Why should portage download some outdated second copy of the
13 sources for 'bar', rebuild it, and scatter it around the file system
14 where it cannot be used by other programs installed by cabal?
15
16 It seems reasonable to me to 'hook' portage into these other package
17 managers, so that running 'emerge bar' would actually run 'cabal install
18 bar' rather than downloading sources and running 'ghc'. This would make
19 managing dependencies much easier as versions change, since most (all?)
20 these alternate package managers have ways of specifying specific
21 versions of packages or pinning. It would also put an end to the
22 breakage caused by, for example, running 'pip' as root and breaking all
23 the python libraries portage has pulled in.
24
25 I also notice that there is a GSoC 2018 project for integrating Rust
26 more closely within Gentoo. It seems to me that allowing ebuilds to be
27 written like this would help resolve this not only for Rust, but for all
28 languages with similar build systems (which is most modern languages,
29 frankly).
30
31 The only real issue I see with this is the potential loss of granularity
32 with USE flags for some of these packages, but having poked around the
33 sort of language-specific libraries and bindings available, hardly any
34 have any USE flags available, and those that do only offer debug symbols
35 or documentation, which many of these other build systems offer as well,
36 so I doubt this would be an issue for anyone. I could of course be wrong.
37
38 Is this a feature/improvement other Gentoo users/developers would be
39 interested in? If so, I would love to help discuss and potentially help
40 with its implementation.

Replies