1 |
On 19-11-2009 19:42:11 -0600, Jeremy Olexa wrote: |
2 |
> Some questions answered. snipped the rest. |
3 |
|
4 |
readded questions where necessary |
5 |
|
6 |
> Denis Dupeyron wrote: |
7 |
> > 2009/10/18 Tomáš Chvátal <scarabeus@g.o>: |
8 |
> >> Why on earth portage simply does not detect the prefix enviroment is being run |
9 |
> >> and then INTERNALY switch D->ED and other variables. |
10 |
> > |
11 |
> > If that means we can get away without touching ebuilds, apart from |
12 |
> > changing their EAPI variable, then that's absolutely what we have to |
13 |
> > do. I'd like things to be done the right way though (see below). |
14 |
> |
15 |
> When you change econf to do --prefix=${EPREFIX}/usr then you cannot |
16 |
> simply s/D/ED/ for everything. I hope this makes sense when you think |
17 |
> about it. ;) |
18 |
> |
19 |
> src_install() { |
20 |
> emake DESTDIR="${D}" install || die |
21 |
> mv "${ED}"/usr/bin/{,exuberant-}ctags || die |
22 |
> } |
23 |
> |
24 |
> But then again, some ebuilds need no changing once you fix econf to do |
25 |
> the work, which is nice. |
26 |
> |
27 |
> > |
28 |
> > On Fri, Nov 13, 2009 at 4:43 AM, Ulrich Mueller <ulm@g.o> wrote: |
29 |
> >> However, there is need for additional discussion. From the council |
30 |
> >> meeting log I could extract the following open questions: |
31 |
> > |
32 |
> > It would be preferable for the discussion to happen on this list |
33 |
> > before the meeting or we'll end up postponing again due to having more |
34 |
> > questions coming up at that time. |
35 |
> |
36 |
> We are willing to talk, but it always seems like the Council is "not |
37 |
> prepared" no matter what we do. Hope everyone involved can change that. |
38 |
> |
39 |
> > |
40 |
> >> 2. Should the Prefix team be allowed to do the necessary changes to |
41 |
> >> ebuilds themselves, or should it be done by the respective |
42 |
> >> maintainers? |
43 |
> > |
44 |
> > I think here it's obvious that anybody who is an ebuild dev and sees |
45 |
> > anything to fix (prefix or else) is encouraged to go ahead and do it, |
46 |
> > as we've always done. The recommendation is and will always be to talk |
47 |
> > to the current maintainers out of politeness and to be extra careful |
48 |
> > (i.e. usually letting the maintainers do it) in case of |
49 |
> > system/tricky/exotic package. We don't give full cvs access to the |
50 |
> > whole tree to all ebuild devs for nothing. |
51 |
> |
52 |
> It is quite obvious that we are not trying to make trouble. Talk is |
53 |
> cheap, so we prefer that. But, we see no need to ask permission to add |
54 |
> ~prefix keywords, same as other arch teams. |
55 |
> |
56 |
> Currently, 'repoman -d full' will fail in some packages. We are fixing this. |
57 |
|
58 |
> > 4. EAPI numbering: Would this simply be added as an additional |
59 |
> > feature to EAPI 3? Or should we have an intermediate EAPI slot, |
60 |
> > e.g. 2.1 or 3 (and current EAPI 3 renamed to 4 in the latter |
61 |
> > case)? |
62 |
> |
63 |
> Here I'd add to the choices: why not release an intermediate EAPI with |
64 |
> the prefix stuff and whatever that has already been done for EAPI3? |
65 |
> The exact name of a potential intermediate EAPI is a non-problem. |
66 |
> However I would prefer if it were a number like 2.1 or 2.5 or even 3, |
67 |
> because although we currently treat the EAPI variable as a simple |
68 |
> string we may change our mind later and find it handy someday to use |
69 |
> operators on them such as >=3D2.1. |
70 |
|
71 |
While I think that this is a totally different discussion, unrelated to |
72 |
Prefix (well, on a side-note, we once had things like EAPI="prefix 1", |
73 |
which denoted both the features from "prefix" and "1"), it is good to |
74 |
isolate things such that it is obvious what an EAPI stands for. |
75 |
|
76 |
> > 5. Who is going to write the exact specification (PMS patch) for |
77 |
> > this EAPI feature? |
78 |
> |
79 |
> I thought I asked Fabian to work on that at the end of the meeting. In |
80 |
> case I didn't then consider this as me officially asking him if he can |
81 |
> take care of it. Fabian is this OK with you? |
82 |
|
83 |
Yes, I agreed coming up with some patch. I admit I haven't yet even |
84 |
looked into it. |
85 |
|
86 |
> Also I think it would be nice if somebody took care of a portage |
87 |
|
88 |
Technically, Portage trunk already contains the most important bits that |
89 |
allow us to continue since yesterday. The rest is waiting for a formal |
90 |
approval of the council, and then it will most probably be me and Zac |
91 |
fighting to get the prefix branch merged into trunk. |
92 |
|
93 |
> > patch, since I hear it is rather simple. Fabian again? Or Zac? Any |
94 |
> > other volunteers? |
95 |
> > |
96 |
> > I would prefer to have all the pieces in places before the next |
97 |
> > meeting so that we can vote on the real thing and have prefix |
98 |
> > implemented the right way before the end of the year. |
99 |
> |
100 |
> portage devs and prefix devs have agreed that it is rather 'easy' to |
101 |
> merge the prefix-portage branch. Just waiting.. ;) We have access to |
102 |
> check into the portage repo, so this should not hold anything up |
103 |
> regarding any decisions. |
104 |
|
105 |
just to repeat: the implementation already exists in the "prefix" branch |
106 |
of the portage repository. |
107 |
|
108 |
> >> 6. (Any question that I've missed?) |
109 |
> |
110 |
> >> How are scripts using #!shebangs going to work? |
111 |
> >> You write an ebuild, and you DEPEND upon >=foo-3, because the build |
112 |
> >> process includes some foo code. The foo code is executed via |
113 |
> >> scripts using #!/usr/bin/foo. Normally, this is fine. |
114 |
> >> But on prefix, /usr/bin/foo might be a crappy, OS X mangled foo-2 |
115 |
> >> that's no good. So even though you've got the foo-3 dep met, it'll be |
116 |
> >> met in /opt/Gentoo/blah, so your package will fail. |
117 |
> |
118 |
> The prefix-portage branch has a nice feature that fixes shebangs |
119 |
> automatically to be ${EPREFIX}/foo instead of /foo. It has even caught |
120 |
> some Gentoo Linux bugs. |
121 |
|
122 |
Next to that, it is part of the Prefix team's job to make sure that |
123 |
whatever is installed, does not reference the host system when this is |
124 |
not absolutely necessary. All of the questions you raise here, are |
125 |
part of the job to get an ebuild "ported" from gx86 to Prefix. In fact, |
126 |
the "crappy, on OS X mangled foo-2" was the main drive to get the |
127 |
project going. |
128 |
|
129 |
> >> How are ebuilds to be marked as supporting prefix or not? |
130 |
> > (Here I'm guessing that changing the EAPI variable will do) |
131 |
> |
132 |
> Gentoo Prefix has keywords. So if EAPI 3 has ED/EROOT support but the |
133 |
> ebuild doesn't use them then the ebuild does not need an EAPI bump. In |
134 |
> this case, please rephrase your question to be "How are ebuilds to be |
135 |
> marked as working on a prefix arch or not?" and then it is clear that it |
136 |
> is the same as Gentoo Linux. |
137 |
> |
138 |
> > |
139 |
> >> Why is there only a single permitted installation path? |
140 |
> > (I'm under the impression this is a limitation of the windows |
141 |
> > installer but not of prefix itself. So patching the installer would |
142 |
> > fix that) |
143 |
> |
144 |
> My installation path on my 6-8 prefix arches is in my NFS home. If you |
145 |
> are referring to the Windows special installation package, well..that is |
146 |
> just a "stage4" installer with binary packages. The windows installer is |
147 |
> no where near the heart of Gentoo Prefix, instead it is a product of |
148 |
> Gentoo Prefix and a convenience factor offered by another Prefix dev. It |
149 |
> showcases the possibilities quite well, IMO. |
150 |
> |
151 |
> You can set EPREFIX to anything. One of our users even set it to "/" - |
152 |
> which we don't endorse but it is possible. :) |
153 |
> |
154 |
> > |
155 |
> >> What exactly is expected from a prefix-compliant package manager to |
156 |
> >> support full prefix installs, as opposed to just supporting installs |
157 |
> >> to / with prefix-aware ebuilds? |
158 |
> > (The PMS patch should answer that) |
159 |
|
160 |
Agreed |
161 |
|
162 |
|
163 |
-- |
164 |
Fabian Groffen |
165 |
Gentoo on a different level |