1 |
On Wed, Mar 7, 2018 at 1:22 PM, R0b0t1 <r030t1@×××××.com> wrote: |
2 |
|
3 |
> On Wed, Mar 7, 2018 at 11:52 AM, Alec Warner <antarus@g.o> wrote: |
4 |
> > On Wed, Mar 7, 2018 at 11:51 AM, Michael Orlitzky <mjo@g.o> |
5 |
> wrote: |
6 |
> >> |
7 |
> >> On 03/07/2018 11:06 AM, anoteros@××××××.io wrote: |
8 |
> >> > Why should portage download some outdated second copy of the |
9 |
> >> > sources for 'bar', rebuild it, and scatter it around the file system |
10 |
> >> > where it cannot be used by other programs installed by cabal? |
11 |
> >> |
12 |
> > |
13 |
> > I'm really not happy with the tone of this email, so I'm going to |
14 |
> comment on |
15 |
> > it a bit. |
16 |
> > |
17 |
> |
18 |
> I can't help but agree with Mr. Orlitzky's sentiment. All language |
19 |
> package managers suffer from the same sophomoric problems: |
20 |
> |
21 |
|
22 |
> 1) I usually don't know where things are downloaded from. |
23 |
> 2) I can't integrate these changes with my distrbution (Gentoo, |
24 |
> Ubuntu, Debian, Fedora, CentOS) safely without serious work. |
25 |
> 3) I can't figure out easily what dependencies a package has. Usually |
26 |
> I see if there are compile or runtime errors. Sometimes the |
27 |
> dependencies are listed somewhere. If the dependency is not what is |
28 |
> currently in e.g. Ubuntu's repository, I may have to maintain separate |
29 |
> versions to be compatible. |
30 |
> 4) Sometimes they aren't set up to be built at all. Let the magic |
31 |
> package manager do everything for you. This works, except when your |
32 |
> shared objects are not in the right places. (But it makes me feel |
33 |
> dirty.) |
34 |
> |
35 |
> >> |
36 |
> >> These other package managers don't solve any hard problems -- they're |
37 |
> >> basically a fancy interface around wget and "git clone." Portage on the |
38 |
> >> other hand has ~20 years of good ideas and hard work on the hard |
39 |
> >> problems in package management. For example... |
40 |
> > |
41 |
> > |
42 |
> > Portage is also full of not-good ideas; many of these we papered over |
43 |
> with |
44 |
> > PMS and EAPI to make |
45 |
> > the actual API people use less horrific. Lets not preach from our ivory |
46 |
> > tower here. |
47 |
> > |
48 |
> |
49 |
> The magnitude of "not good" is, I would suggest, very different. |
50 |
> |
51 |
> Cabal is a pretty hilarious example. Have you ever tried to build it |
52 |
> without using the release binaries? I suppose this is a second problem |
53 |
> though, where people want to be "self-reliant" and instead just end up |
54 |
> making things impossible to verify or make reproducible. |
55 |
> |
56 |
> For the longest time Cabal did not authenticate or verify the code it |
57 |
> would run (as root). Very recently this was fixed, but I still feel |
58 |
> bad any time I let it run, even if it's on a separate development |
59 |
> system. |
60 |
> |
61 |
|
62 |
Gentoo just got signature checking enabled by default...in ~arch? I'm not |
63 |
sure if that version of portage is stable yet. |
64 |
Like I said, be careful how one preaches from the ivory tower. |
65 |
|
66 |
|
67 |
> |
68 |
> >> |
69 |
> >> > It seems reasonable to me to 'hook' portage into these other package |
70 |
> >> > managers, so that running 'emerge bar' would actually run 'cabal |
71 |
> install |
72 |
> >> > bar' |
73 |
> >> |
74 |
> >> Can "cabal install" build or even identify the C libraries that your |
75 |
> >> Haskell package needs? No, because nobody ever thought of that, and it |
76 |
> >> seems kind of hard now that the cabal build system has no ability to |
77 |
> >> build non-Haskell packages, so no one is ever going to work on it. |
78 |
> >> |
79 |
> >> Can "cabal install" rebuild your Haskell packages when the ABI of some |
80 |
> >> library changes? No, because "cabal install" doesn't have any idea |
81 |
> >> what's installed on your system. |
82 |
> >> |
83 |
> >> Can "cabal install" uninstall a package? Nope, it has no idea what was |
84 |
> >> done during the installation, and thus no idea what to undo. |
85 |
> >> |
86 |
> >> Can "cabal install" verify the integrity of your downloaded source code? |
87 |
> >> No, because by design it fetches and runs code from complete strangers. |
88 |
> >> |
89 |
> >> Can "cabal install" use a local tarball to function without network |
90 |
> >> access? Etc. We're dead in the water. |
91 |
> >> |
92 |
> >> Every other language-specific package manager has the same problems, |
93 |
> >> because they're all written by people who didn't know anything about |
94 |
> >> package management and then got bored when they realized that there's |
95 |
> >> more to it than parsing a json file of dependencies. |
96 |
> >> |
97 |
> > |
98 |
> > They are written by people who are not you, who have different problems |
99 |
> than |
100 |
> > you and often don't care about the above use cases. |
101 |
> > It turns out this stuff exists because: |
102 |
> > |
103 |
> > 1) Upstream wants to push 1 single thing and have it work in all distros. |
104 |
> > 2) pip / virtualenv / cargo / whatever work reasonable well. |
105 |
> > 3) Rolling-based distros couldn't keep up with packaging. |
106 |
> > 4) Snapshot-based distros (debian stable / ubuntu) were not designed with |
107 |
> > this in mind as much; because packages were developed with a high |
108 |
> velocity. |
109 |
> > |
110 |
> |
111 |
> |
112 |
This == upstream has a git tag (release X) and they sync the tag into pip |
113 |
and they tell people to pip install X and their job is done. |
114 |
Software, distributed. |
115 |
|
116 |
|
117 |
> 1) What do you mean by this? Distributions are usually not binary |
118 |
> compatible. This "works" by having each distribution customize and |
119 |
> build a project by hand. |
120 |
> |
121 |
|
122 |
Right, and because "distributions" move a different speeds (Ubuntu, Debian, |
123 |
Gentoo) and have different branches (testing, stable, unstable, ~arch, |
124 |
pmask) |
125 |
this is all even *more* overhead for developers to worry about. So they use |
126 |
pip, and they don't (worry about it.) |
127 |
|
128 |
|
129 |
|
130 |
> 2) Virtualenv works well, and cabal now has a local installation |
131 |
> option. Still, these are not perfect. |
132 |
> 3) Use a git ebuild, or target stable versions. If a project has so |
133 |
> much churn that I can't keep up with it I will find something more |
134 |
> stable. |
135 |
> |
136 |
|
137 |
I don't think Ubuntu ships git-ebuilds (because it doesn't have ebuilds) so |
138 |
I'm stuck consuming some PPA (either one that upstream builds, or some |
139 |
shady PPA run by who knows who that build my binaries.) |
140 |
|
141 |
Easier to pip install! |
142 |
|
143 |
|
144 |
> 4) True, but prefix would be a lot better at fixing that problem. If |
145 |
> not that, something like virtualenv. |
146 |
> |
147 |
> In the case of either #3 or #4, the distribution developers prefer you |
148 |
> use their package manager to install packages. You are only safe doing |
149 |
> anything else in an environment like virtualenv, which does not exist |
150 |
> for the vast majority of languages. This is why developers will pass |
151 |
> around VM images, or devote an entire VM to development on a project. |
152 |
> Languages and their packages are not designed to be compartmentalized |
153 |
> and will trash your installation. |
154 |
|
155 |
|
156 |
Containers are certainly awesome, yep. |
157 |
|
158 |
|
159 |
> There is also (going along with #4): |
160 |
> 5) The software may need to work on Windows. They could have used |
161 |
> Cygwin or MSYS2. Anything else is an exercise in futility. People have |
162 |
> come before you and done it better. |
163 |
> |
164 |
|
165 |
> Taken together these issues boil down to "the people rewriting package |
166 |
> managers don't realize the problems they actually have" which agrees |
167 |
> with what was said. As above, the typical workflows of these people |
168 |
> involve lots of VMs or containers. Ask yourself "why?" |
169 |
> |
170 |
|
171 |
Because containers are awesome and are way easier to use. |
172 |
|
173 |
-A |
174 |
|
175 |
|
176 |
> |
177 |
> > |
178 |
> >> |
179 |
> >> If you want to eliminate the duplication of effort, tell these people to |
180 |
> >> use Gentoo Prefix instead of writing the N+1st crippled PM. Doing it the |
181 |
> >> other way around won't work because we'd be replacing one good thing |
182 |
> >> with 75 shitty things. |
183 |
> > |
184 |
> > |
185 |
> > I agree that in theory they could have published ebuilds for Gentoo |
186 |
> prefix |
187 |
> > and it would have 'worked everywhere' but I think that boat sailed about |
188 |
> 10 |
189 |
> > years ago. |
190 |
> > |
191 |
> > https://wiki.gentoo.org/wiki/Project:Perl/g-cpan is a project is in a |
192 |
> > similar space and basically reads perl CPAN metadata to generate stub |
193 |
> > ebuilds. |
194 |
> > Portage tracks these stub ebuilds (and so for example, it tracks what |
195 |
> these |
196 |
> > cpan packages install and can remove them afterwards.) |
197 |
> > |
198 |
> > I think this is the most pragmatic approach I've seen used as its mostly |
199 |
> an |
200 |
> > adapter (to cpan) that just generates ebuilds. |
201 |
> > Its plausible that with some careful eclass magic you might be able to |
202 |
> make |
203 |
> > the installed packages compatible with pip, cargo, etc. |
204 |
> > |
205 |
> > I think its more of a struggle to make it compatible with things like |
206 |
> > virtualenv or pip --user though. |
207 |
> > |
208 |
> |
209 |
> This might be a good way to relieve the amount of intervention |
210 |
> required when repackaging code for an actual package manager. The |
211 |
> information should be there. The other option is convincing people to |
212 |
> package for multiple systems at once, which diffuses the effort to the |
213 |
> point people tend to not mind. |
214 |
> |
215 |
> 1) Language package manager (usually used by Windows consumers). |
216 |
> 2) .debs for Ubuntu/Debian. |
217 |
> 3) .rpms for Fedora/CentOS. |
218 |
> 4) Sometimes there's a Gentoo or Arch release. |
219 |
> |
220 |
> If you could sell #4 as a way to generate 1-3 it would likely be |
221 |
> possible to reduce the proliferation of language specific package |
222 |
> managers over time. Prefix would likely play an important role. |
223 |
> |
224 |
> Cheers, |
225 |
> R0b0t1 |
226 |
> |
227 |
> |