Stuart Herbert wrote:
On Tuesday 11 January 2005 21:15, Francesco Riosa wrote:my bad explaining, /etc/init.d/mysql is the *same* (md5 sums) for all mysql versions, it's called via symlinks to know wich one to start, if say mysql 5 need a different way to start it will install a real file /etc/init.d/mysql-5.0 and leave there /etc/init.d/mysql-4.X symlinks to /etc/init.d/mysql
Trying to keep all toghether, there is still one my.cnf file and one
/etc/init.d/mysql script (plus simlink, like net.eth*)
Hrm ... SLOT'ed packages aren't allowed to overwrite files installed by other packages (including versions of itself in other SLOTs). This would need fixing.
An alternative should be create a /etc/conf.d/mysql file but in that case you can start only one mysql server at time.
The only drawback I can see is having a lot of mysql*-X.Y and symlink
files instead of mysql* but it seem reasonable o me.
There are a number of packages which have optional support for mysql. How many of them install if you only have MySQL 4.1 installed on a box using your ebuild?
very few, I think this is the mayor need of a slotted mysql installation.
We do already have the 'mysqli' global USE flag, so that ebuilds can differentiate between depending on MySQL 4.0 and 4.1.Seen in mysql packages that in DEPEND you can have "<dev-db/mysql-4.1*" or "<dev-db/mysql-5.0*"
Personally, after the experience of supporting PHP and a SLOT'ed Apache, I'm not sure it's such a good idea to SLOT major packages like MySQL. SLOTing major packages works, but the user experience is ... kludgy I guess is the word. We end up using USE flags and global calls to has_version() (which is a QA violation) to make the best of it.Apache and php are not born to be slotted, they have chosen other roads, php try to keep a backward compatibility for example.
Mysql seems not very interested in that, they do changes that really change, often making thing not compiling. Discuss who is right is a secure flamefest.
May be for this reasons I found easy the work to slot it. there are configure options that do the trick for you, the configure file is suited to be used at the same time from more servers versions, the mysql database *is* backward compatible, and so commenting skip-locking you can have different databases running on the same files at the same time. Still some work is needed for the shell scripts, and to have different core databases.
The improvement needed in Portage seems very straight-forward. Heck, maybe Portage already works this way and I haven't realised it ;-)Complex, I've readed it three times ;) It seem the best solution, maybe with the addition that if an upgrade of both A and B exist and A is supported from B portage should upgrate both automatically (or I need to read the 4th).
Assume B depends on A, and that A is a SLOTed package. If A is already installed, only attempt to install versions of B which depend atoms match against the version of A already installed. When upgrading B, don't upgrade A if the upgrade will install A into a different SLOT. If the user wants to upgrade A to a version that goes into a different SLOT, require the user to explicitly upgrade package A.
USE flags can be used by the user to choose which version of A he gets to start off with. I don't think we could ever drop those USE flags, because they'll still be needed by B's DEPEND statement in some cases. The global has_versions() are no longer required (they can be moved into src_compile(), where they'll still be needed for passing the right options to configure).Why the utilization of use flags to choose the version ? emerge ">cat-egory/name-x.y.z" (or <) isn't enought ?
There's probably a corner case or two that I've overlooked, but if that was ever added to Portage, that'd make a world of difference to the Apache and PHP packages.
Best regards,
Stu
Best regards Francesco
-- [email protected] mailing list
