mysql-5.0.34.ebuild have checking of berkdb USE-flag inside of it. But it is not listed in it's IUSE. So this flag affects building, but it does not showed to user. Also building fails with this flag enables on compiling bdb. Because of missing environment variable SED. Whith it its OK. May be this bug in portage - I doesn't know if it allowes of using "use berkdb" when berkdb is not in IUSE. My portage version is 2.1.2.1
@vivo - WTH is this ebuild re-implementing the whole eclass within it???
Fixing it myself in both mysql and mysql-community, don't ever again commit such stuff! Best regards, CHTEKK.
(In reply to comment #1) > @vivo - WTH is this ebuild re-implementing the whole eclass within it??? I've been requested to move the eclass in the ebuild from Robin because the eclass used to create more harm than good into stable keyworded mysql packages. (In reply to comment #2) > Fixing it myself in both mysql and mysql-community, don't ever again commit > such stuff! > Best regards, CHTEKK. CHTEKK, manage the dev-db/mysql and I'll be happily stay in my retirement, or never again tell me what I can or cannot commit (kind suggestion are still apreciated).
(In reply to comment #3) > (In reply to comment #1) > > @vivo - WTH is this ebuild re-implementing the whole eclass within it??? > > I've been requested to move the eclass in the ebuild from Robin because the > eclass used to create more harm than good into stable keyworded mysql packages. Uhhh? Then please kindly inform me too, and state what those problems are, I haven't seen any... And just copying the whole eclass into the ebuild won't solve any problems, can't see how that's possible at all... > (In reply to comment #2) > > Fixing it myself in both mysql and mysql-community, don't ever again commit > > such stuff! > > Best regards, CHTEKK. > > CHTEKK, manage the dev-db/mysql and I'll be happily stay in my retirement, or > never again tell me what I can or cannot commit (kind suggestion are still > apreciated). I do manage it, when I have time, I'm very busy atm with other things... Still plz first talk to all the other MySQL herd members. Best regards, CHTEKK.
I specifically asked vivo to move the eclass contents specific to the various package trees into them, given that he was leaving, I had a strong preference for maintaining them as independant builds, esp. given the past troubles with Manifest generation and the bugs we recieved because people did not update their trees properly.
(In reply to comment #5) > I specifically asked vivo to move the eclass contents specific to the various > package trees into them, given that he was leaving, I had a strong preference > for maintaining them as independant builds, esp. given the past troubles with > Manifest generation and the bugs we recieved because people did not update > their trees properly. > Cool, I was not informed of this... I have strong preference for using one eclass instead of duplicating code across 10 ebuilds, and the current approach works... The only case in which something could go wrong was if arch-teams didn't update their eclass/ dir, which happened like 1 time, and then we added the warning, and it never happened again since... I also don't think this as an argument for killing the eclass at all... Please leave it as is now, a lot of work was spent n making it work, and it does work, correctly! Best regards, CHTEKK.
vivo asked me, and I'm reasonably certain that it was mentioned in at least one email to the mysql-bugs alias. One of the other problems I had with it, is that when it came to changing the eclass for fixing libtool stuff (eg my fixes for 5.0.34 most recently), it would be more of a pain in the arse to check that every single ebuild still worked with the eclass, since they all relied on it.
(In reply to comment #7) > vivo asked me, and I'm reasonably certain that it was mentioned in at least one > email to the mysql-bugs alias. I didn't know, and I just checked all mail from mysql-bugs@g.o and there is nothing in the last 90 days that mentions the word eclass and talks about such a change, so I'm pretty sure it was never sent to mysql-bugs@g.o. > One of the other problems I had with it, is that when it came to changing the > eclass for fixing libtool stuff (eg my fixes for 5.0.34 most recently), it > would be more of a pain in the arse to check that every single ebuild still > worked with the eclass, since they all relied on it. Well, I ported that to the main eclass now, cause I'm pretty sure the others will fail too without the fix... It's just pure concidence that people noticed failures with libtool-1.5.23b+mysql-5.0.34, cause both were put in ~ARCH at about the same time, and ~ARCH users did get the updates, which then broke. Best regards, CHTEKK.
(In reply to comment #8) > Well, I ported that to the main eclass now, cause I'm pretty sure the others > will fail too without the fix... Just to be 100% sure I now tested the following combos with your fix in the eclass: mysql 5.0.26-r2 + libtool-1.5.22 mysql 5.0.26-r2 + libtool-1.5.23b mysql 5.0.34 + libtool-1.5.22 mysql 5.0.34 + libtool-1.5.23b Naturally with berkdb enabled, and they all worked fine now, so the fix correctly fixes the problem for all versions it seems. ;) Also, if you want to have code that only affects one or select mysql versions, that can easily be done in the eclass too, using one of the mysql version check functions. It's then also easier to see what changed from one version to the other, and those are generally little changes anyway. Best regards, CHTEKK.
one of the other problems I have, is that unless I go nuts and lock down a change in the ebuild to a specific revision, it's a pain to test out specific changes while having them easily revertable by users - quite simply, merging mysql at two times when the eclass has changed lead to different results, and non-repeatability sucks. That said, i'll leave the eclass alone now, but if I'm stuck with maintaining mysql myself (vivo may be leaving, and I don't know how you you are sticking around chktekk, you seemed awol for a bit) - I'm going to convert it back to the non-eclass style.
(In reply to comment #10) > That said, i'll leave the eclass alone now, but if I'm stuck with maintaining > mysql myself (vivo may be leaving, and I don't know how you you are sticking > around chktekk, you seemed awol for a bit) - I'm going to convert it back to > the non-eclass style. Uhm... There're 9 ebuilds using the eclass right now, 25K of code in the eclass -> that's almost 250K of redundant cruft to maintain if you do this. Kinda fail to see the advantage of nuking the eclass and bloating the ebuilds. Just my € 0.02.
