1 |
Some questions answered. snipped the rest. |
2 |
|
3 |
Denis Dupeyron wrote: |
4 |
> 2009/10/18 Tomáš Chvátal <scarabeus@g.o>: |
5 |
>> Why on earth portage simply does not detect the prefix enviroment is being run |
6 |
>> and then INTERNALY switch D->ED and other variables. |
7 |
> |
8 |
> If that means we can get away without touching ebuilds, apart from |
9 |
> changing their EAPI variable, then that's absolutely what we have to |
10 |
> do. I'd like things to be done the right way though (see below). |
11 |
|
12 |
When you change econf to do --prefix=${EPREFIX}/usr then you cannot |
13 |
simply s/D/ED/ for everything. I hope this makes sense when you think |
14 |
about it. ;) |
15 |
|
16 |
src_install() { |
17 |
emake DESTDIR="${D}" install || die |
18 |
mv "${ED}"/usr/bin/{,exuberant-}ctags || die |
19 |
} |
20 |
|
21 |
But then again, some ebuilds need no changing once you fix econf to do |
22 |
the work, which is nice. |
23 |
|
24 |
> |
25 |
> On Fri, Nov 13, 2009 at 4:43 AM, Ulrich Mueller <ulm@g.o> wrote: |
26 |
>> However, there is need for additional discussion. From the council |
27 |
>> meeting log I could extract the following open questions: |
28 |
> |
29 |
> It would be preferable for the discussion to happen on this list |
30 |
> before the meeting or we'll end up postponing again due to having more |
31 |
> questions coming up at that time. |
32 |
|
33 |
We are willing to talk, but it always seems like the Council is "not |
34 |
prepared" no matter what we do. Hope everyone involved can change that. |
35 |
|
36 |
> |
37 |
>> 2. Should the Prefix team be allowed to do the necessary changes to |
38 |
>> ebuilds themselves, or should it be done by the respective |
39 |
>> maintainers? |
40 |
> |
41 |
> I think here it's obvious that anybody who is an ebuild dev and sees |
42 |
> anything to fix (prefix or else) is encouraged to go ahead and do it, |
43 |
> as we've always done. The recommendation is and will always be to talk |
44 |
> to the current maintainers out of politeness and to be extra careful |
45 |
> (i.e. usually letting the maintainers do it) in case of |
46 |
> system/tricky/exotic package. We don't give full cvs access to the |
47 |
> whole tree to all ebuild devs for nothing. |
48 |
|
49 |
It is quite obvious that we are not trying to make trouble. Talk is |
50 |
cheap, so we prefer that. But, we see no need to ask permission to add |
51 |
~prefix keywords, same as other arch teams. |
52 |
|
53 |
Currently, 'repoman -d full' will fail in some packages. We are fixing this. |
54 |
|
55 |
> Also I think it would be nice if somebody took care of a portage |
56 |
> patch, since I hear it is rather simple. Fabian again? Or Zac? Any |
57 |
> other volunteers? |
58 |
> |
59 |
> I would prefer to have all the pieces in places before the next |
60 |
> meeting so that we can vote on the real thing and have prefix |
61 |
> implemented the right way before the end of the year. |
62 |
|
63 |
portage devs and prefix devs have agreed that it is rather 'easy' to |
64 |
merge the prefix-portage branch. Just waiting.. ;) We have access to |
65 |
check into the portage repo, so this should not hold anything up |
66 |
regarding any decisions. |
67 |
|
68 |
> |
69 |
>> 6. (Any question that I've missed?) |
70 |
|
71 |
>> How are scripts using #!shebangs going to work? |
72 |
>> You write an ebuild, and you DEPEND upon >=foo-3, because the build |
73 |
>> process includes some foo code. The foo code is executed via |
74 |
>> scripts using #!/usr/bin/foo. Normally, this is fine. |
75 |
>> But on prefix, /usr/bin/foo might be a crappy, OS X mangled foo-2 |
76 |
>> that's no good. So even though you've got the foo-3 dep met, it'll be |
77 |
>> met in /opt/Gentoo/blah, so your package will fail. |
78 |
|
79 |
The prefix-portage branch has a nice feature that fixes shebangs |
80 |
automatically to be ${EPREFIX}/foo instead of /foo. It has even caught |
81 |
some Gentoo Linux bugs. |
82 |
|
83 |
> |
84 |
>> How are ebuilds to be marked as supporting prefix or not? |
85 |
> (Here I'm guessing that changing the EAPI variable will do) |
86 |
|
87 |
Gentoo Prefix has keywords. So if EAPI 3 has ED/EROOT support but the |
88 |
ebuild doesn't use them then the ebuild does not need an EAPI bump. In |
89 |
this case, please rephrase your question to be "How are ebuilds to be |
90 |
marked as working on a prefix arch or not?" and then it is clear that it |
91 |
is the same as Gentoo Linux. |
92 |
|
93 |
> |
94 |
>> Why is there only a single permitted installation path? |
95 |
> (I'm under the impression this is a limitation of the windows |
96 |
> installer but not of prefix itself. So patching the installer would |
97 |
> fix that) |
98 |
|
99 |
My installation path on my 6-8 prefix arches is in my NFS home. If you |
100 |
are referring to the Windows special installation package, well..that is |
101 |
just a "stage4" installer with binary packages. The windows installer is |
102 |
no where near the heart of Gentoo Prefix, instead it is a product of |
103 |
Gentoo Prefix and a convenience factor offered by another Prefix dev. It |
104 |
showcases the possibilities quite well, IMO. |
105 |
|
106 |
You can set EPREFIX to anything. One of our users even set it to "/" - |
107 |
which we don't endorse but it is possible. :) |
108 |
|
109 |
> |
110 |
>> What exactly is expected from a prefix-compliant package manager to |
111 |
>> support full prefix installs, as opposed to just supporting installs |
112 |
>> to / with prefix-aware ebuilds? |
113 |
> (The PMS patch should answer that) |
114 |
> |
115 |
> Denis. |
116 |
> |