1 |
On Wed, Mar 7, 2018 at 11:51 AM, Michael Orlitzky <mjo@g.o> wrote: |
2 |
|
3 |
> On 03/07/2018 11:06 AM, anoteros@××××××.io wrote: |
4 |
> > Why should portage download some outdated second copy of the |
5 |
> > sources for 'bar', rebuild it, and scatter it around the file system |
6 |
> > where it cannot be used by other programs installed by cabal? |
7 |
> |
8 |
> |
9 |
I'm really not happy with the tone of this email, so I'm going to comment |
10 |
on it a bit. |
11 |
|
12 |
|
13 |
> These other package managers don't solve any hard problems -- they're |
14 |
> basically a fancy interface around wget and "git clone." Portage on the |
15 |
> other hand has ~20 years of good ideas and hard work on the hard |
16 |
> problems in package management. For example... |
17 |
> |
18 |
|
19 |
Portage is also full of not-good ideas; many of these we papered over with |
20 |
PMS and EAPI to make |
21 |
the actual API people use less horrific. Lets not preach from our ivory |
22 |
tower here. |
23 |
|
24 |
|
25 |
> |
26 |
> |
27 |
> > It seems reasonable to me to 'hook' portage into these other package |
28 |
> > managers, so that running 'emerge bar' would actually run 'cabal install |
29 |
> > bar' |
30 |
> |
31 |
> Can "cabal install" build or even identify the C libraries that your |
32 |
> Haskell package needs? No, because nobody ever thought of that, and it |
33 |
> seems kind of hard now that the cabal build system has no ability to |
34 |
> build non-Haskell packages, so no one is ever going to work on it. |
35 |
> |
36 |
> Can "cabal install" rebuild your Haskell packages when the ABI of some |
37 |
> library changes? No, because "cabal install" doesn't have any idea |
38 |
> what's installed on your system. |
39 |
> |
40 |
> Can "cabal install" uninstall a package? Nope, it has no idea what was |
41 |
> done during the installation, and thus no idea what to undo. |
42 |
> |
43 |
> Can "cabal install" verify the integrity of your downloaded source code? |
44 |
> No, because by design it fetches and runs code from complete strangers. |
45 |
> |
46 |
> Can "cabal install" use a local tarball to function without network |
47 |
> access? Etc. We're dead in the water. |
48 |
> |
49 |
> Every other language-specific package manager has the same problems, |
50 |
> because they're all written by people who didn't know anything about |
51 |
> package management and then got bored when they realized that there's |
52 |
> more to it than parsing a json file of dependencies. |
53 |
> |
54 |
> |
55 |
They are written by people who are not you, who have different problems |
56 |
than you and often don't care about the above use cases. |
57 |
It turns out this stuff exists because: |
58 |
|
59 |
1) Upstream wants to push 1 single thing and have it work in all distros. |
60 |
2) pip / virtualenv / cargo / whatever work reasonable well. |
61 |
3) Rolling-based distros couldn't keep up with packaging. |
62 |
4) Snapshot-based distros (debian stable / ubuntu) were not designed with |
63 |
this in mind as much; because packages were developed with a high velocity. |
64 |
|
65 |
|
66 |
|
67 |
|
68 |
> If you want to eliminate the duplication of effort, tell these people to |
69 |
> use Gentoo Prefix instead of writing the N+1st crippled PM. Doing it the |
70 |
> other way around won't work because we'd be replacing one good thing |
71 |
> with 75 shitty things. |
72 |
|
73 |
|
74 |
I agree that in theory they could have published ebuilds for Gentoo prefix |
75 |
and it would have 'worked everywhere' but I think that boat sailed about 10 |
76 |
years ago. |
77 |
|
78 |
https://wiki.gentoo.org/wiki/Project:Perl/g-cpan is a project is in a |
79 |
similar space and basically reads perl CPAN metadata to generate stub |
80 |
ebuilds. |
81 |
Portage tracks these stub ebuilds (and so for example, it tracks what these |
82 |
cpan packages install and can remove them afterwards.) |
83 |
|
84 |
I think this is the most pragmatic approach I've seen used as its mostly an |
85 |
adapter (to cpan) that just generates ebuilds. |
86 |
Its plausible that with some careful eclass magic you might be able to make |
87 |
the installed packages compatible with pip, cargo, etc. |
88 |
|
89 |
I think its more of a struggle to make it compatible with things like |
90 |
virtualenv or pip --user though. |
91 |
|
92 |
-A |