Re: [gentoo-dev] SLOTed MySQL or not?
No dev but +1 from me. I liked slotted mysql a lot and use it extensively. It has helped us tremendously during our upgrade path and I would be very sad to see it go. Public opinion is just that, public opinion, doesn't neccesarily mean something went wrong. FWIW, I'd like to keep the slotted mysql ebuilds. If they are removed from the tree I'll re-add them to our local frozen tree for our company. We're not a hosting company BTW, we just run lots of mysql daemons ;-) Ramon -- To be stupid and selfish and to have good health are the three requirements for happiness, though if stupidity is lacking, the others are useless. Gustave Flaubert -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SLOTed MySQL or not?
Ramon van Alteren wrote: No dev but +1 from me. I liked slotted mysql a lot and use it extensively. It has helped us tremendously during our upgrade path and I would be very sad to see it go. Public opinion is just that, public opinion, doesn't neccesarily mean something went wrong. FWIW, I'd like to keep the slotted mysql ebuilds. If they are removed from the tree I'll re-add them to our local frozen tree for our company. We're not a hosting company BTW, we just run lots of mysql daemons ;-) Ramon Slotted MySQL will definitely go away from the main Portage tree, there only the normal MySQL ebuilds will remain. Atm we're setting up an overlay for MySQL, so there you'll still be able to download the slotted ebuilds and eventually if someone's intersted he can maintain them/bring them to a usable, better state or whatever, but we (MySQL Herd) won't do that at the moment and will only maintain and provide non-slotted MySQL ebuilds. -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
[gentoo-dev] Lugcamp 2006 in Ofterschwang / Germany
Howdy, from 25. - 28.05.2006 there will be the yearly Lugcamp in Ofterschwang, Southern Germany/Border to Austria. In contrast to other events, this is only a small, non-commercial event to enjoy meet-and-greet, having fun doing useful/useless things and some sightseeing if your're interested. And yes, there are some speeches, too but they're not the reason for being there ;). Last year it was in Wuppertal. It even got a small report on TV which can be downloaded here: http://lugcamp.digital-family.de/wdr_bericht.mpg (It was sent on WDR, german television, so it is in german as well) If you need more information, everything required is available at http://www.lugcamp.org Preregistration is required as there are only a limited amount of seats available ;) A small note about Ofterschwang: It is only a small town but well known as the Ski Worldcup has a competition there every year. If you're still searching this small town, you can find it here: http://tinyurl.com/r36aq I hope to see some of you there :) Markus signature.asc Description: OpenPGP digital signature
[gentoo-dev] USE_EXPAND in IUSE ( again )
So folks seem to want things both ways. Some people believe that USE_EXPAND'd variables are private: || I have yet to be enlightened on any merit of USE_EXPAND is so perhaps || you could explain as to why there should be || user-configured-yet-undocumented options for ebuilds? More precisely, || how should they be documented if not via use.desc? | |1. Because for things like LINGUAS, there are arbitrarily many legal |values, and documenting them all and keeping the list up to date would |be extremely difficult. | |2. Because USE_EXPAND is used for special USE things like arch and |userland, and because we undocumented the special arch USE flags |because they're not user settable. That leaves a couple of things, first off, how do users figure out that a particular setting affects an ebuild. If I have no VIDEO_CARDS set, for example, how do I as a user figure out that that the new modular X ebuilds actually use VIDEO_CARDS? Secondly, some USE_EXPAND'd things are user-settable, and some are not. Arguably, some may belong in IUSE, others are just not appropriate ( VIDEO_CARDS and LINGUAS both being rather large and difficult to maintain. The current state of things is that: 1. Repoman complains to developers when they use USE_EXPAND in IUSE and there are not entries in use.desc This check for USE_EXPAND'd variables can be turned off, if the community feels that USE_EXPAND should remain undocumented. Or we can commit Diego's patch that reads USE_EXPAND descriptions from $PORTDIR/profiles/desc/USE_EXPAND.desc 2. Portage complains about USE_EXPAND flags not in IUSE when they are used, because they are not user settable. This ties into the above, either USE_EXPAND flags modify ebuilds publically (IUSE) or they modify it privately ( no IUSE ). I don't really want to see it both ways, as we then need a constant list of USE_EXPAND flags that are supposed to set off warnings versus those that don't. Or we just kill the warnings for any USE_EXPAND variable, which I hope the QA team will comment on. 3. Jason Stubbs has commited code in portage 2.1 to show USE_EXPAND flags in output. I'm not sure who likes or dislikes this, but depending on that outcome of this discussion, that code may need to be modified. Conclusion: Either USE_EXPAND always goes in IUSE, or USE_EXPAND never goes in IUSE. If you want USE_EXPAND that sometimes goes in IUSE and sometimes doesn't you better have a good plan for keeping those lists of proper USE_EXPAND flags and improper flags in sync. I mean I'd love to do it that way, but I'll bet those lists get old and nasty and we will have people complaining about QA warnings that they thought were fixed or that there were no QA warnings when there should have been...etc.. -Other ideas are always welcome; I'd prefer to get this solved soon. -Alec Warner signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] USE_EXPAND in IUSE ( again )
On Saturday 11 March 2006 14:19, Alec Warner wrote: Either USE_EXPAND always goes in IUSE, or USE_EXPAND never goes in IUSE. Regardless of what is displayed, portage will eventually need to know what USE_EXPAND env vars are modifying the behaviour of an ebuild. Consider extending --newuse to support USE_EXPAND as well. Simply knowing the var itself isn't quite enough. Could you imagine if every single package that is modified by USE were recompiled when irrelevant parts of USE is changed? If you want USE_EXPAND that sometimes goes in IUSE and sometimes doesn't you better have a good plan for keeping those lists of proper USE_EXPAND flags and improper flags in sync. I mean I'd love to do it that way, but I'll bet those lists get old and nasty and we will have people complaining about QA warnings that they thought were fixed or that there were no QA warnings when there should have been...etc.. I also committed support for a USE_EXPAND_HIDDEN. Individual flags don't need to be added to it. USE_EXPAND_HIDDEN=USERLAND ARCH ... is enough. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Move PORTAGE_INST_UID and PORTAGE_INST_GID to make.globals?
On Mar 10, 2006, at 4:26 AM, Zac Medico wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, What do people think about moving PORTAGE_INST_UID and PORTAGE_INST_GID to make.globals? Would the profiles not be a more logical place to set these? If not, can we twist the logic to make it so? :p --Kito -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Enabling RSYNC_OPTIONS to be set in make.conf
On Fri, 2006-03-10 at 14:38 -0600, Robert Larson wrote: Hello list, I am needing to allow for further configuration of rsync for syncing portage. The addition of RSYNC_OPTIONS in make.conf could alleviate this need for me, but what do you guys think? [snip] I think genone has a more complete patch for this already. If he has not committed it already I'm sure he will soon. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
