Re: [gentoo-dev] [RFC] multislot mysql
On Fri, 2006-02-03 at 10:19 +, Francesco Riosa wrote: Ok, I've been realized that having a slotted mysql is not the dream of every end user ... or developer. Anyway I prefere too keep the possibility to do a similar install. A good solution should be to add the multislot USE flag to the ebuild and let it to decide whenever make it slotted or not, sorry, this is not viable, yes it's already used by other important packages but not well supported by portage and should be used only in particular situations. The only thing that came in mind to me is to provide two series of ebuilds, with different revision ranges. The use flag multislot will still have a role, to make the ebuild fail during pkg_setup() if set on the wrong ebuild. It's possible to define the default ebuild to merge, assigning a greater revision number will make an ebuild the default installed, I suggest the un-slotted version to be the default. example: mysql-4.1.16-r[0..49] Need +multislot mysql-4.1.16-r[50..99] Need -multislot mysql-5.1.18-r[0..49] Need +multislot mysql-5.1.18-r[50..99] Need -multislot whoever want to have a slot version will need to mask revisions between 50 and 99 . The change will happen soon, between today and tomorrow, so toughts, flames and insults are well accepted. - Francesco R. I really don't like this... It will give users more work to maintain their systems... Managing /etc/portage/ isn't easy, and forcing the users to use it, isn't good too. I speak for mysql: [EMAIL PROTECTED] ~ $ cat /etc/portage/package.keywords | wc -l 53 ^^ And this was about 100 before i did a cleanup to it. What i sugest is to create a diferent package, mysql-{slotted,}. You guys from the mysql herd can use the same ebuils to both packages (the content i mean) and just check the ${PN} for the slotted word to see if the package is slotted or not Just my 0.02€ -- Carlos r3pek Silva Gentoo Developer (kernel/amd64/mobile-phone) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] multislot mysql
Carlos Silva wrote: On Fri, 2006-02-03 at 10:19 +, Francesco Riosa wrote: Ok, I've been realized that having a slotted mysql is not the dream of every end user ... or developer. Anyway I prefere too keep the possibility to do a similar install. A good solution should be to add the multislot USE flag to the ebuild and let it to decide whenever make it slotted or not, sorry, this is not viable, yes it's already used by other important packages but not well supported by portage and should be used only in particular situations. The only thing that came in mind to me is to provide two series of ebuilds, with different revision ranges. The use flag multislot will still have a role, to make the ebuild fail during pkg_setup() if set on the wrong ebuild. It's possible to define the default ebuild to merge, assigning a greater revision number will make an ebuild the default installed, I suggest the un-slotted version to be the default. example: mysql-4.1.16-r[0..49] Need +multislot mysql-4.1.16-r[50..99] Need -multislot mysql-5.1.18-r[0..49] Need +multislot mysql-5.1.18-r[50..99] Need -multislot whoever want to have a slot version will need to mask revisions between 50 and 99 . The change will happen soon, between today and tomorrow, so toughts, flames and insults are well accepted. - Francesco R. I really don't like this... It will give users more work to maintain their systems... Managing /etc/portage/ isn't easy, and forcing the users to use it, isn't good too. I speak for mysql: [EMAIL PROTECTED] ~ $ cat /etc/portage/package.keywords | wc -l 53 ^^ And this was about 100 before i did a cleanup to it. What i sugest is to create a diferent package, mysql-{slotted,}. You guys from the mysql herd can use the same ebuils to both packages (the content i mean) and just check the ${PN} for the slotted word to see if the package is slotted or not Just my 0.02€ I'm going to assume that user _don't_ want a slotted mysql . Not forcing the users to mess with /etc/portage is exactly what I try to achieve here. Assuming the ebuilds are already marked stable (and btw un-slotted MUST be marked stable before or at the same time then slotted). This case if u remove totally /etc/portage you will have a un-slotted mysql installed, of the best version avaiable, isn't this what we want to achieve ? Having a different package is doable but also a un-useful tree cluttering. Also I assume that if the user want to have a slotted MySQL version he/she/they can cope with some entries in /etc/portage to achieve the result. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] multislot mysql
On Fri, Feb 03, 2006 at 10:19:18AM +, Francesco Riosa wrote: A good solution should be to add the multislot USE flag to the ebuild and let it to decide whenever make it slotted or not, sorry, this is not viable, yes it's already used by other important packages but not well supported by portage and should be used only in particular situations. [snip] example: mysql-4.1.16-r[0..49] Need +multislot mysql-4.1.16-r[50..99] Need -multislot mysql-5.1.18-r[0..49] Need +multislot mysql-5.1.18-r[50..99] Need -multislot NAK. Do not go the route of ranged revisions for specific features. If you go with multislot, you must make it work in ALL revisions. One of the reasons why is that portage does not support a limited ranged dep properly last I checked, so this is hard for everybody to deal with. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpshGb2EUbw1.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] multislot mysql
Honestly, I don't see why is this needed. It works the same way like apache slots or php slots or whatever other slots. If users emerge an ebuild explicitely, they get the highest version available, if they want something else, they can do echo =dev-db/mysql-5* /etc/portage/package.mask That's exactly the same amount of user intervention required as if they should enable multislot use flag in package.keywords instead (considering that users definitely don't want to enable such flag globally for things like binutils or gcc). Also, the current behaviour doen not take away the possibility for other ebuilds to depend on a specific slotted mysql version, e.g. if something doesn't work with 5.x but works just fine with 4.1. That won't be possible once multislot use flag is required for slotted install. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpfEOpvV3PGc.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] multislot mysql
Robin H. Johnson wrote: On Fri, Feb 03, 2006 at 10:19:18AM +, Francesco Riosa wrote: A good solution should be to add the multislot USE flag to the ebuild and let it to decide whenever make it slotted or not, sorry, this is not viable, yes it's already used by other important packages but not well supported by portage and should be used only in particular situations. [snip] example: mysql-4.1.16-r[0..49] Need +multislot mysql-4.1.16-r[50..99] Need -multislot mysql-5.1.18-r[0..49] Need +multislot mysql-5.1.18-r[50..99] Need -multislot NAK. Do not go the route of ranged revisions for specific features. If you go with multislot, you must make it work in ALL revisions. One of the reasons why is that portage does not support a limited ranged dep properly last I checked, so this is hard for everybody to deal with. Robin, Jakub, I can see your points here, for the moment I will left things as is, still open to alternatives. Francesco -- gentoo-dev@gentoo.org mailing list