On 6/9/07, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
* Kent Fredric <[EMAIL PROTECTED]> wrote:
> Ah, but you see, in half the cases there is not a /complete/
> incompatibility. PHP4<->5 migration is not an entirely big switch,
> the biggest problem IIRC in the 4->5 change is the way it handles
> classes, and a lot of code 'simply works' on both.
I had to do a lot at that front. Believe me, they're NOT compatible.
Just nearly compatible. So different.
For those packages where it really doesnt matter, we simply could
use an virtual.
Sama for java.
So, your suggesting the following would have been a better option in this case
dev-lang/php4/php4-4.4.3.ebuild
dev-lang/php4/php4-4.4.4.ebuild
dev-lang/php5/php5-5.1.1.ebuild
dev-lang/php5/php5-5.2.0.ebuild
virtual/php/php-5.ebuild -> dev-lang/php5/php5-5.2.0.ebuild
virtual/php/php-4.ebuild -> dev-lang/php4/php4-4.4.4.ebuild
... and ... to have .. slotted virtuals like jdk does =P (this does
give the added benefit that if somebody else were to create a PHP
engine they could just jump into the virtual, or if one day php5 were
to be /fully/ backwards compatible with php4 its version could be
dumped into the php4 virtual and allow people to upgrade .. )
So either way you look at it, its just a case of /where/ the slotting
occurs, not whether or not it occurs.
<snip>
> In the case of autoconf, im personally glad it all hides under one
> non-linear space-time-continumum on my harddrive ;) . The thought of
> them all being in seperate ebuild names would drive me nutty ( folder
> with 10 different package names for the same thing = wtf? )
What "folders" are you tallking about ?
sys-devel/automake/automake-1.10.ebuild
sys-devel/automake/automake-1.4_p6.ebuild
sys-devel/automake/automake-1.5.ebuild
sys-devel/automake/automake-1.6.3.ebuild
sys-devel/automake/automake-1.7.9-r1.ebuild
sys-devel/automake/automake-1.8.5-r3.ebuild
sys-devel/automake/automake-1.9.6-r2.ebuild
as theres 1 slot here /per/ ebuild, it would cause a bit of namespace
pollution were you to "upslot" them, ie:
instead of just one nice sys-devel/automake , you would need to have
sys-devel/automake-1.10/automake-1.10-1.10.ebuild
sys-devel/automake-1.4/automake-1.4-1.4_p6.ebuild
sys-devel/automake-1.5/automake-1.5-1.5.ebuild
sys-devel/automake-1.6/automake-1.6-1.6.3.ebuild
sys-devel/automake-1.7/automake-1.7-1.7.9-r1.ebuild
sys-devel/automake-1.8/automake-1.8-1.8.5-r3.ebuild
sys-devel/automake-1.9/automake-1.9-1.9.6-r2.ebuild
Which IMO would produce horror stories you could tell to your children,
especially if many other packages currently utilizing slotting were to
go that way.
<snip>
> The argument of 'cleaning' was a problem for a little while, but im
> glad the kernel uses slotting, for the reason I dont want to have a
> seperate ebuild for different kernels, i dont want old kernel sources
> to be taken away when the new one turns up, and when i want to get rid
> of old kernels, i want to be able to do a nice and simple emerge -C
> <=some-version to get rid of them when im done with them.
Okay, that's good point where slots are really useful.
But I'm sure there could be other good solutions.
> The same occurs in many of the web-applications, where multiple versions
> are handy, but multiple ebuild names would cause headaches.
hmm, they're an special things, since we can have many instances
of the same application here. but I never had the need to have
multiple versions of one webapp (source) installed.
The reason for this, I believe, is that webapps regularly need to be
hand-adjusted to suit the users needs, and needs hand tuning for each
upgrade. Often this automated upgrade can break stuff ( can, but if
you've not changed from default, it usually runs fine ), so I guess
the reason is similar to the kernels, "less stuff breaking" i guess. (
Although ATM, its unobvious how to switch between webapp slots :S )
> the only way to get around all these nasties would be to have a 3 part
> package name imo, such as
> dev-libs/gtk/2/2.0.1.ebuild
> dev-libs/gtk/1/1.0.1.ebuild
> for instance , and when you look at it like that, it is in essence
> identical to 'slots', except a 'slot' is governed by a string in the
> actual file, instead of a string in the filename.
Well, if the slot number would be an part of the package atom name,
it would be half as bad.
I definately aggree, which would help many apps out in following
problem slotting currently has : "It is not possible to DEPEND upon a
package in a specific slot." [1]
For some things, such as things which require automake, & friends, it
would permit them to use some sort of syntax such as
%=sys-devel/automake-1.9
%<=sys-devel/automake-1.9
%>=sys-devel/automake-1.9
Why that syntax ?
Well , we have a dilemour, if we were to change the way package atoms
were named, it would break /craploads/ of the stuff already available
expecting the 'old way'
how do we make this easy to use?
Heres my proposition, and thats slot-files.
Like virtuals, but on a per-package level. (Cos virtuals are really
designed to handle multiple packages that provide the same function,
not one package which produces multiple different functions )
sys-devel/automake/automake-1.9.slot <-- note the suffix.
This file would contain none-other than a list of packages which
comprise that slot.
packages emerged without -1 would be injected into world as a 'user
asked for this slot' ie: %sys-devel/automake-1.9
thus preventing the erronious cleaning of slots, and permitting
packages to directly depend on a given slot.
In essence, this does what we did with virtuals. Virtuals I believe,
either used to be defined in some global text file, or as a string
inside each packages ebuild, but my memorys a bit rusty as to exactly
how it used to work.
This suggestion, is a de-ebuilding of slotting control somewhat.
Now these are just my suggestions to how we could fix your oppositon
of the current slotting system, and perhaps improve gentoos slot
function without breaking it for all existing things.
Your thoughts & suggestions appreciated.
*1 http://devmanual.gentoo.org/general-concepts/slotting/index.html
--
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil [EMAIL PROTECTED]"[(2*x)..(2*x+1)]}'
--
[EMAIL PROTECTED] mailing list
