Gentoo Archives: gentoo-dev

From: Kent Fredric <kentnl@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Integrating Portage with other package managers
Date: Sat, 10 Mar 2018 05:26:57
Message-Id: 20180310182614.177f9cbb@katipo2.lan
In Reply to: [gentoo-dev] Integrating Portage with other package managers by anoteros@teknik.io
1 On Wed, 7 Mar 2018 11:06:47 -0500
2 anoteros@××××××.io wrote:
3
4 > Having used Gentoo for a few years now, one thing that has been annoying
5 > to me is the tremendous duplication of effort and uphill battle of
6 > creating ebuilds (build recipes) for language-specific packages that
7 > already have their own build systems.
8
9 As much as this would be nice, for some ecosystems this is entirely impossible.
10
11 Notably, Perl would be an impossible target, because instead of using
12 package level dependencies like Gentoo does, it uses module level dependencies.
13
14 A package has >= 1 module. And to make matters interesting, "the
15 package" a given module ships in can change as a function of time.
16
17 Sometimes, 2 packages fuse to become 1, and other times, 1 splits to
18 become 2.
19
20 Within CPAN, this happens pretty transparently, mostly because they
21 don't actually have an ahead-of-time dependency resolution system.
22
23 Dependency resolution is performed via:
24
25 1. Get the module name
26 2. Fetch a copy of the index
27 3. Look up module name in index
28 4. Install resolved package
29
30 And that "index" is updated every time a new package is uploaded.
31
32 Which basically means that system is only useful for asking the
33 question "Where is the latest version of X", not "where is Y version of
34 X"
35
36 And to add insult to injury, CPAN's versioning scheme is incompatible
37 with Gentoo's.
38
39 ( They have a right to, they had both versions and package management
40 before we did )
41
42 We have a hack of sorts to circumnavigate the version scheme[1]
43 situation, but it only works in one direction ( eg: you can convert
44 CPAN versions to normalised Gentoo versions, but not vice versa )
45
46 But solving the package/module version resolution missmatch is an
47 ongoing nightmare which all my efforts have so far concluded, that only
48 humans are capable of solving, and a large volume of my efforts
49 engaging with upstream have been driven by this single problem.
50
51 Native integration would be really nice, but alas, the best of my
52 understanding so far is its a giant fantasy that attracts lots of
53 people with good ideas, that ultimately all fail in application. ( And
54 part of that is because the upstream you're dealing with is not a
55 machine, but another human who is prone to deviating from spec on a
56 regular basis enough to cause headaches for us )
57
58 1: https://wiki.gentoo.org/wiki/Project:Perl/Version-Scheme