1 |
On 6/9/07, Enrico Weigelt <weigelt@×××××.de> wrote: |
2 |
> * Kent Fredric <kentfredric@×××××.com> wrote: |
3 |
> |
4 |
> > Ah, but you see, in half the cases there is not a /complete/ |
5 |
> > incompatibility. PHP4<->5 migration is not an entirely big switch, |
6 |
> > the biggest problem IIRC in the 4->5 change is the way it handles |
7 |
> > classes, and a lot of code 'simply works' on both. |
8 |
> |
9 |
> I had to do a lot at that front. Believe me, they're NOT compatible. |
10 |
> Just nearly compatible. So different. |
11 |
> For those packages where it really doesnt matter, we simply could |
12 |
> use an virtual. |
13 |
> |
14 |
> Sama for java. |
15 |
|
16 |
|
17 |
So, your suggesting the following would have been a better option in this case |
18 |
|
19 |
dev-lang/php4/php4-4.4.3.ebuild |
20 |
dev-lang/php4/php4-4.4.4.ebuild |
21 |
dev-lang/php5/php5-5.1.1.ebuild |
22 |
dev-lang/php5/php5-5.2.0.ebuild |
23 |
|
24 |
virtual/php/php-5.ebuild -> dev-lang/php5/php5-5.2.0.ebuild |
25 |
virtual/php/php-4.ebuild -> dev-lang/php4/php4-4.4.4.ebuild |
26 |
|
27 |
... and ... to have .. slotted virtuals like jdk does =P (this does |
28 |
give the added benefit that if somebody else were to create a PHP |
29 |
engine they could just jump into the virtual, or if one day php5 were |
30 |
to be /fully/ backwards compatible with php4 its version could be |
31 |
dumped into the php4 virtual and allow people to upgrade .. ) |
32 |
So either way you look at it, its just a case of /where/ the slotting |
33 |
occurs, not whether or not it occurs. |
34 |
|
35 |
> |
36 |
> <snip> |
37 |
> |
38 |
> > In the case of autoconf, im personally glad it all hides under one |
39 |
> > non-linear space-time-continumum on my harddrive ;) . The thought of |
40 |
> > them all being in seperate ebuild names would drive me nutty ( folder |
41 |
> > with 10 different package names for the same thing = wtf? ) |
42 |
> |
43 |
> What "folders" are you tallking about ? |
44 |
|
45 |
sys-devel/automake/automake-1.10.ebuild |
46 |
sys-devel/automake/automake-1.4_p6.ebuild |
47 |
sys-devel/automake/automake-1.5.ebuild |
48 |
sys-devel/automake/automake-1.6.3.ebuild |
49 |
sys-devel/automake/automake-1.7.9-r1.ebuild |
50 |
sys-devel/automake/automake-1.8.5-r3.ebuild |
51 |
sys-devel/automake/automake-1.9.6-r2.ebuild |
52 |
|
53 |
as theres 1 slot here /per/ ebuild, it would cause a bit of namespace |
54 |
pollution were you to "upslot" them, ie: |
55 |
|
56 |
instead of just one nice sys-devel/automake , you would need to have |
57 |
|
58 |
sys-devel/automake-1.10/automake-1.10-1.10.ebuild |
59 |
sys-devel/automake-1.4/automake-1.4-1.4_p6.ebuild |
60 |
sys-devel/automake-1.5/automake-1.5-1.5.ebuild |
61 |
sys-devel/automake-1.6/automake-1.6-1.6.3.ebuild |
62 |
sys-devel/automake-1.7/automake-1.7-1.7.9-r1.ebuild |
63 |
sys-devel/automake-1.8/automake-1.8-1.8.5-r3.ebuild |
64 |
sys-devel/automake-1.9/automake-1.9-1.9.6-r2.ebuild |
65 |
|
66 |
Which IMO would produce horror stories you could tell to your children, |
67 |
especially if many other packages currently utilizing slotting were to |
68 |
go that way. |
69 |
|
70 |
|
71 |
|
72 |
|
73 |
> <snip> |
74 |
> |
75 |
> > The argument of 'cleaning' was a problem for a little while, but im |
76 |
> > glad the kernel uses slotting, for the reason I dont want to have a |
77 |
> > seperate ebuild for different kernels, i dont want old kernel sources |
78 |
> > to be taken away when the new one turns up, and when i want to get rid |
79 |
> > of old kernels, i want to be able to do a nice and simple emerge -C |
80 |
> > <=some-version to get rid of them when im done with them. |
81 |
> |
82 |
> Okay, that's good point where slots are really useful. |
83 |
> But I'm sure there could be other good solutions. |
84 |
> |
85 |
> > The same occurs in many of the web-applications, where multiple versions |
86 |
> > are handy, but multiple ebuild names would cause headaches. |
87 |
> |
88 |
> hmm, they're an special things, since we can have many instances |
89 |
> of the same application here. but I never had the need to have |
90 |
> multiple versions of one webapp (source) installed. |
91 |
|
92 |
The reason for this, I believe, is that webapps regularly need to be |
93 |
hand-adjusted to suit the users needs, and needs hand tuning for each |
94 |
upgrade. Often this automated upgrade can break stuff ( can, but if |
95 |
you've not changed from default, it usually runs fine ), so I guess |
96 |
the reason is similar to the kernels, "less stuff breaking" i guess. ( |
97 |
Although ATM, its unobvious how to switch between webapp slots :S ) |
98 |
|
99 |
> > the only way to get around all these nasties would be to have a 3 part |
100 |
> > package name imo, such as |
101 |
> > dev-libs/gtk/2/2.0.1.ebuild |
102 |
> > dev-libs/gtk/1/1.0.1.ebuild |
103 |
> > for instance , and when you look at it like that, it is in essence |
104 |
> > identical to 'slots', except a 'slot' is governed by a string in the |
105 |
> > actual file, instead of a string in the filename. |
106 |
> |
107 |
> Well, if the slot number would be an part of the package atom name, |
108 |
> it would be half as bad. |
109 |
|
110 |
|
111 |
I definately aggree, which would help many apps out in following |
112 |
problem slotting currently has : "It is not possible to DEPEND upon a |
113 |
package in a specific slot." [1] |
114 |
|
115 |
For some things, such as things which require automake, & friends, it |
116 |
would permit them to use some sort of syntax such as |
117 |
|
118 |
%=sys-devel/automake-1.9 |
119 |
%<=sys-devel/automake-1.9 |
120 |
%>=sys-devel/automake-1.9 |
121 |
|
122 |
|
123 |
Why that syntax ? |
124 |
|
125 |
Well , we have a dilemour, if we were to change the way package atoms |
126 |
were named, it would break /craploads/ of the stuff already available |
127 |
expecting the 'old way' |
128 |
|
129 |
how do we make this easy to use? |
130 |
|
131 |
Heres my proposition, and thats slot-files. |
132 |
Like virtuals, but on a per-package level. (Cos virtuals are really |
133 |
designed to handle multiple packages that provide the same function, |
134 |
not one package which produces multiple different functions ) |
135 |
|
136 |
sys-devel/automake/automake-1.9.slot <-- note the suffix. |
137 |
|
138 |
This file would contain none-other than a list of packages which |
139 |
comprise that slot. |
140 |
packages emerged without -1 would be injected into world as a 'user |
141 |
asked for this slot' ie: %sys-devel/automake-1.9 |
142 |
thus preventing the erronious cleaning of slots, and permitting |
143 |
packages to directly depend on a given slot. |
144 |
|
145 |
In essence, this does what we did with virtuals. Virtuals I believe, |
146 |
either used to be defined in some global text file, or as a string |
147 |
inside each packages ebuild, but my memorys a bit rusty as to exactly |
148 |
how it used to work. |
149 |
This suggestion, is a de-ebuilding of slotting control somewhat. |
150 |
|
151 |
Now these are just my suggestions to how we could fix your oppositon |
152 |
of the current slotting system, and perhaps improve gentoos slot |
153 |
function without breaking it for all existing things. |
154 |
|
155 |
Your thoughts & suggestions appreciated. |
156 |
|
157 |
|
158 |
*1 http://devmanual.gentoo.org/general-concepts/slotting/index.html |
159 |
-- |
160 |
Kent |
161 |
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x| |
162 |
print "enNOSPicAMreil kdrtf@×××.com"[(2*x)..(2*x+1)]}' |
163 |
-- |
164 |
gentoo-user@g.o mailing list |