mysql's configure-script has the option --without-server, i think this should be made configurable through a make-variable... i have several machines here that act only as client to another machine with the mysql-server, and i have to compile the whole server on the client-machines to get client-functionality... or maybe create a new ebuild mysqlclient that builds only the client, either way! bye, stephan
nope, not going to do this. 1) this is not the gentoo way 2) where do you draw the line? you realize that several other packages can also do this (client + server component) 3) im not going to make an exception just for mysql 4) if you realy want this, then i suggest you start a crusade to do this to -ALL- packages in the portage tree that can support it. And by this I mean you submit fixes and patches to make this happen, you do not just submit a bug report: "please enable client + server for ALL packages in the portage tree please" 5) you can alraedy do this yourself. I suggest you edit your ebuild file. And before you begin to complain, I suggest you realize that the ebuilds are not meant to be not edited. Do you really think nobody edits their ebuild files before merging them? Lots of people customise their ebuilds to fit their own needs. Since this is so simple, why dont you just take the 20 seconds to edit your own local ebuild file. Regards.
plus, this functionality is coming (so that you dont have to edit every ebuild for every upgrade ...)
Currently I appreciate the availability of the ebuild for mysql -but- it is a trivial task to make another ebuild file for client only is it not? We used redhat here for a while and got used to not having to install mysql server if we only needed libs or clients. I would like to think that the 'Gentoo way' is not to bloat systems with unneeded packages but instead provide best functionality. If my workstation only needs the MySQL-libs then that's all I want. IMHO comments like that tend to cause people to loose faith in the developers that work on these projects. Please consider changing your view on this issue. -Paul
i'd be happy if someone told what exactly the gentoo way _is_... noone answered me on my personal reply! i really thought that the gentoo way is, like mentioned in the prior post, to have a system that fits perfectly to one's needs, but i guess i was wrong... and like i wrote in the personal mail i think that this could have been told in a far less aggressive mail...
Ok I just lost 30mins worth of comments I wrote up about this. That sucks and I dont feel like recreating them all again. I'll give you the very short version now: Are you even aware that subpackages in the RPM world are all defined from a single .spec file? According to your solution, we should create additional -EBUILDS- for client, server, dev-libs, docs, manpages, etc, etc. Well, that solution, quite frankly, sucks. BUT. Your -end result- is noble. Let me be perfectly clear about that. I too would like to be able to get only the server portion, or only the client portion, etc, etc. But not at the expense of bloating the entire portage tree. What about postgresql? What about SAMBA? What about bind? How many packages could take advantage of this? Dozens? Hundreds? Thousands? *Shudder* Sorry pal, but I'm not going to bloat the portage tree with 4-5 ebuilds *per* package. If you want bloat, then there you go, witness your proposed "trivial solution". I imagine you wont be around to update the 5 MySQL ebuilds when a fix or new release is made, right? But you'll find it awful convenient to send in a new "please update all 5 ebuilds, theres a new release". Right? Ok, so what do we do ... Well, portage should get some added functionality. A -single- ebuild file should be able to define subpackages for client, server, maybe docs, manpages, etc. This is the -only- sane way to do this. There used to be comments at the top of portage.py hinting to the proposed implementation strategy of subpackages. I dont know if they're there anymore, why dont you go take a look. I dont hack on portage, so I dont know the best way to implement it. All I know is, once that functionality is in place, then -ALL- ebuilds in the portage tree could define the subpackages, and our developers wouldnt have to use your proposed nonsensical solution of creating/maintaining 5 separate ebuilds for -each- package that could take advantage. I hope you're on my page now. I'll definately write the subpackage definitions for MySQL, etc, ONCE portage is taught about them. But to bloat the portage tree with 5 ebuilds for each package is completely nonsense.
ok, you're right. accepted. what you say is reasonable, and maybe there will be extra functionality for subpackages, and we're all happy. so please take my apologize! but please, when someone else who isn't writing ebuilds on his own, or hacking the portage tree, asks for something that he thinks is great, but in your eyes doesn't make sense, tell him that. don't be so angry about him, just because he doesn't know better. doesn't really help to get gentoo (or linux) spread by not-so-experienced users...
All valid points. I've used the spec files to help with ebuilds locally, it's trivial. As far as there being 100's of seperate ebuilds for libs/clients/servers etc. well, there are only a couple I can really think of off-hand that are done that way namely Samba and MySQL (both maintained by you?) This is not a huge issue and I apologize if my comments were upsetting to you, if this functionality is not an option because of the number of builds then I'll just maintain my own ebuilds at this location for my systems (20+). Thanks for your time and keep up the good work.
Sorry, but consider this: I can almost -gaurantee- you that by the time subpackages are implemented on a portage level, I'll receive more requests for this very thing. And then I'll have to explain it a l l o v e r a g a i n. Which is completely frustrating because I've been maintaining these packages for way more than a year now and have already danced to this tune several times before. The most frustrating part for me, is getting a snotty request for this from somebody who thinks they're so smart, that to not implement their proposed idea must indicate me being a dickhead or just being stupid. Well sorry, but as I say, I've been over this too many times and have all but given up hope that people will -think- before they use bugs.gentoo.org as either their own personal source for technical support, or a place to dump suggestions without hardly -any- thought into the greater picture of what's going on. No, they just want what they want, and want it now. And I'm not going to play along. I appreciate your latter comments, both of you, very generous of you to accept my position whilst being bitched at by me at the same time. Believe me, I know it might not be pleasant to be on the other side of this exchange. But trust me, I'm a nice guy. I dont receive a dime for all over the work I've done on this distribution for the last two years. Not a free video card. No sponsorship. Nothing. So personally whatever keeps the workload down while being a sane implementation idea gets my vote.
Understood. Not even a video card? ;-) Take care -Paul
ok, your point. i know what you're talking about, i'm developing web-applications for a big german car-producer, and i have to give support for all these idiotic little questions that are mainly wrong usage... but like i stated before, i agree with you that if it's against the gentoo way it shouldn't even be considered, but _what is_ the gentoo way? why not explain it on the gentoo.org frontpage? also, when you've received stuff like this again and again, why not make it a theme for the weekly newsletter? a news-entry on the frontpage? or even put it in the ebuild as a comment? i really searched for info's about this on the forums, and in the bug-database but couldn't find a thing. and it _could_ have been (yes, of course, the chances are low...) that knoone thought about this, and because of that i entered a bug-report. so please spread these information, and i'll bet these request will get less over time (of course there are always moron's that post before researching... but don't count me in ;-) ) chapter closed (for my side)
When I say the "Gentoo way" I'm simply referring to the fact that we don't currently have the split like several other RPM-based distributions: samba-client samba-common samba-doc samba-server samba-swat samba-winbind MySQL MySQL-Max MySQL-bench MySQL-client What a mess. Basically, currently, in Gentoo you have -ONE- ebuild file which you merge and you get -everything-. Simple. Sweet. Easy to manage. Now we're getting to the point where we almost have to do the same thing (split subpackages like other distros) because Gentoo is getting more and more users. One of the reasons for sure why we've grown so fast, and been ported to so many different architectures is definately because the build recipes (ebuilds) are very simple. Easy to extend. Easy to maintain. Easy to learn. Etc. So to do the -devel, -server, -client, -doc stuff is not really "The Gentoo" way. That's all I was saying. Look at Mandrake's PHP packages. If I log into their FTP server and do: dir php* i get back about 20 packages! I see both sides of the issue. Easier and lighter weight to just get the portions of a package you desire, but also waaay more confusing. How do you know which subpackages you _really_ need? If there is only -1- package for mysql then you install that package and you have it all. No guessing required. Which is why I've offered no implementation ideas or proposals. I really dont know what the best way to implement the subpackages idea is ... hopefully somebody will come up with something good. At any rate, they really need to be defined in a single ebuild file, similar to how everybody else defines their subpackages in the other distributions in a single .spec file or rules file etc. Yuck!
