1 |
On Tue, 2009-05-26 at 08:48 +0000, Duncan wrote: |
2 |
> Philipp Riegger <lists@××××××××××××.de> posted |
3 |
> 1243321504.9661.14.camel@×××××××××××××××××××××××××××××××.de, excerpted |
4 |
> below, on Tue, 26 May 2009 09:05:03 +0200: |
5 |
> |
6 |
> > I don't see the connection between the email Fabio wrote and your |
7 |
> > answer. Do you want to say, that you agree that he's doing what i |
8 |
> > described and that it works the way i described it? I doubt it. If you |
9 |
> > really care, could you answer my first email and state there the |
10 |
> > problems you see with the approach and why you think this is making |
11 |
> > Gentoo worse? |
12 |
> |
13 |
> I agree that an independent approach is the way to go. Gentoo (or |
14 |
> rather, its PMs, package managers, all three of them, of which portage is |
15 |
> only one) doesn't do binaries really well, certainly, but I really don't |
16 |
> see that changing within Gentoo itself, except at the expense of from- |
17 |
> source, which it does quite well indeed. |
18 |
|
19 |
Again, I see this as completely independent "features". Binary packages |
20 |
would only support the building from source and binary packages could |
21 |
never be created without ebuilds. This might even improve the quality of |
22 |
the ebuilds in the tree, because they would get built from time to time, |
23 |
build failures would get reported and all that. |
24 |
|
25 |
> > But how would you make it worse? It already has the functionality to add |
26 |
> > repositories for binpackages, why not improve it? Why leave it the way |
27 |
> > it is? |
28 |
> |
29 |
> Sure, improve it, but what you are talking about isn't a simple |
30 |
> improvement, but a massive rearchitecting. That's not easily doable |
31 |
> without a chance of focus. It's that change of focus that would |
32 |
> eventually kill the quality from-source support we have and that |
33 |
> continues to develop, now. |
34 |
|
35 |
Are you sure? How code would it take to look for a binary package in a |
36 |
different path than now? 1 additional line or 1 line exchanged? How much |
37 |
code would it take to create this packed bit vector out of the |
38 |
USE-flags? 5-10 lines? Changing portage to _also_ support the new kind |
39 |
of binary packages might be done in 1 day. And this is the first step. |
40 |
|
41 |
> >> That said, I could envision an eselect like "binary profile" switcher, |
42 |
> >> that subject to settings in a config file, changes USE flags, CFLAGS, |
43 |
> >> gcc- configs an appropriate gcc version, etc, changing PKGDIR |
44 |
> >> appropriately as well, so one could easily enough create as many |
45 |
> >> "binary profiles" as desired and as the use case dictated. |
46 |
> |
47 |
> > Not sure, what the binary profile switcher really would change here. |
48 |
> > What I was talking about were mostly USE-flags and packages, and I guess |
49 |
> > your binary profile switcher doesn't change too much, there. |
50 |
> |
51 |
> Sure it does, but incrementally. Basically, your proposal laid out a |
52 |
> complicated tree based on metadata, a tree the package manager would have |
53 |
> to understand and support, what I'm proposing is to allow the same thing, |
54 |
> but not by adding all that complication to the package manager, but |
55 |
> rather, by using a newly created application to switch among the branches |
56 |
> of that tree on request. |
57 |
|
58 |
Which might work, but would lead to a really strange package tree with |
59 |
really big restrictions and disadvantages (no package sharing, no way of |
60 |
finding out if an update is necessary,...). |
61 |
|
62 |
> Portage (or other PM) would use its configured |
63 |
> PKGDIR and wouldn't understand the tree, but it wouldn't need to, because |
64 |
> the switcher would manage switching between the branches according to its |
65 |
> configuration. |
66 |
|
67 |
And there the flexibility goes. If you want to emerge PHP and there is a |
68 |
binary package with the same USE-flage but also cli enabled or something |
69 |
like that, it would really get complicated to inform you (the user) that |
70 |
a simple and probably not too important change for you might save you an |
71 |
hour of compilation. |
72 |
|
73 |
> The result would be that in a large enough deployment to have build- |
74 |
> servers, the build server(s) could build a particular set of CFLAGS/USE- |
75 |
> flags/gcc-version/arch/whatever, then switch to another branch and build |
76 |
> that set. Individual package clients could simply point at the |
77 |
> appropriate tree and get most of their packages, at least the common |
78 |
> ones, that way. |
79 |
> |
80 |
> Now this wouldn't directly give you the flexibility of the package name |
81 |
> changes you proposed, but it could do so indirectly, putting that |
82 |
> information in the directory tree if configured to do so. Clients may |
83 |
> need to use the binprofile switcher as well, for individual packages they |
84 |
> chose to build outside their normal USE profile, but the process could be |
85 |
> automated once properly configured, using PM hooks as appropriate. |
86 |
|
87 |
And as soon as you use PM hooks, you ask yourself, why you did it that |
88 |
way, if not that change had made it easier, if it would have been better |
89 |
to discuss the issue with portage/pkgcore/paludis developers and all |
90 |
that. |
91 |
|
92 |
Since I really like PM hooks, I'm not sure if they are really helpfull |
93 |
for users. They are too cryptic. Maybe it would be wise to create some |
94 |
eselect like thing for those hooks provide some basic scripts with that. |
95 |
|
96 |
|
97 |
> For that matter, Gentoo already has three package managers, and binary |
98 |
> support (or the lack thereof) has been deliberately left up to the |
99 |
> package manager at this point -- it's NOT part of PMS. It'd be equally |
100 |
> possible to either take one of the current PMs and add your enhanced |
101 |
> binary package scheme to it, or to start an independent forth package |
102 |
> manager, and have it focus on binaries rather than from-source. (It |
103 |
> could even take the existing portage binpkgs and rename or otherwise |
104 |
> manage them as necessary, thereby avoiding the from-source side entirely, |
105 |
> if so desired.) |
106 |
> |
107 |
> > Well, the last is a little bit impossible outside of Gentoo |
108 |
> > (I don't want to fork the tree) and I also don't want to fork portage, |
109 |
> > so the first is complicated, too. |
110 |
> |
111 |
> You mention portage, but don't mention the other PMs at all. As |
112 |
> mentioned, binary packages aren't part of PMS (the Package Management |
113 |
> Specification, the app-doc/pms package, the standard that allows PMs |
114 |
> besides portage, currently, paludis and pkgcore) at all. Gentoo really |
115 |
> doesn't have an official binary package format at all (see PMS, Appendix |
116 |
> B, Unspecified Items), only individual package managers like portage do, |
117 |
> and at present they may conflict with each other. |
118 |
> |
119 |
> That's both a good and a bad thing. As it's not specified, you're free |
120 |
> to define it as necessary to meet your needs for any tool you devise to |
121 |
> handle binary packages. Of course, that means that it's just that tool's |
122 |
> definition, and at least one package manager, portage, does happen to |
123 |
> have binary packages and a working format definition for them. |
124 |
> |
125 |
> But that leaves you with maximum flexibility in creating whatever you |
126 |
> want, either as a separate tool (or even independent Gentoo based |
127 |
> distribution), or as an expanded PM, either forked from one of the |
128 |
> current ones, or created independently. |
129 |
|
130 |
Now, while flexibility migth be interesting for developers and power |
131 |
users, I don't think it's always the right thing for users. |
132 |
|
133 |
Why not talk about binary packages, work on a standard and write some |
134 |
draft for PMS or another document (not like "you need this", but like |
135 |
the special annexes from ada for example which leave it open to be |
136 |
implemented or not). Now we have sabayon. We have the portage binary |
137 |
packages. How many more do we need until we realize, that it only |
138 |
duplicates work? |
139 |
|
140 |
> > And all this layer thing Fabio was talking about. I did not try it and I |
141 |
> > did not read the code, but I think it makes things much more |
142 |
> > complicated. See also the discussion about mixing package managers |
143 |
> > between Gentoo and Sabayon. I do not want these problems. |
144 |
> |
145 |
> But your proposal adds the complexity that would bring these problems, |
146 |
> whether you want them or not. Either way, the technical problems can be |
147 |
> worked thru, it's simply a matter of coding for the most part, after all, |
148 |
> but the problems are there and must be dealt with either way. You prefer |
149 |
> to have Gentoo do it as a whole. I say no, leave Gentoo well enough |
150 |
> alone in that regard, and let individual projects, either as Gentoo-based |
151 |
> independent distributions, or at the application (either PM or switcher |
152 |
> level) deal with the problems. After all, Gentoo's a big organization |
153 |
> and getting all of it together addressing a problem is a VERY hard task |
154 |
> as I'm sure CiaranM among others can vouch for. A much smaller PM or |
155 |
> switcher app project is by definition of the smaller size, also much |
156 |
> easier to steer and to get things actually done in. |
157 |
|
158 |
While it might be difficult, it might just be worth it. |
159 |
|
160 |
Bit it seems to be quite an uninteresting topic, since the people most |
161 |
affected by it (Gentoo developers) did not join the conversation, yet. |
162 |
Maybe I should take this to gentoo-server@ and gentoo-portage@, it might |
163 |
fit there. |
164 |
|
165 |
Philipp |