Well, I know this has already been brought up on -core by seemant ... ... anyway, here's what I'd like to see in the near(?) future (especially when portage will handle "sticky" USE) : In the portage tree, in a per client/server basis, we already have packets "splitted" (such as bind (server) and bind-tools (clients), or that needs to be splitted (of course, that's not a complete list yet): - gkrellm2 - netkit-* - openssh - tightvnc Wouldn't be easier and more convenient if we had a "server" and a "client" USE flag ? Example: 1) `USE="client" emerge bind' would install the clients (the query tools), i.e. dig,bind,nslookup 2) `USE="server" emerge bind' would install the server part (init scripts, the named executable, configs, etc) 3) `USE="server client" emerge bind' would install both server and client stuff. 4) If nor "client" neither "server" is defined both server and client stuff will be installed. Doesn't all this sound cool? That way we would: - offer a dramatically increased flexibility. (i.e. you will be able to install *exactly* what you need) - reduce the number of ebuilds (to avoid contributing to increase the stuff to rsync) Please lemme know what you guys thinks about that. - maurizio
sounds nice to me :) definitely wort a though . ;)
Just my thought, I'll check this with the ebuild review thread on the forums (they are reviewing ebuilds for better USE flag support).
I think it would be ok, if we added a non-default USE flag called "expert" I'm planning on adding an "expert" like USE flag to xfree ebuilds soon, so maybe that can be extended from local to global. That way, if "expert" is not set, then you get both server and client. Specifically: "-expert server -client" builds server and client "expert server client" also builds server and client "expert server -client" server only "expert -server client" client only Thoughts?
I don't think that a client USE flag is necessary and it would be difficult to implement as many packages have switches to disable server support but not client support. Also it would dependency checking difficult as packages might depend on client-libraries and -tools but unlikely depend on server binaries.
Ok my thoughts... (after reading http://bugs.gentoo.org/show_bug.cgi?id=22219) I don't think that server/client should be set in the USE flag. The ebuilds will be very complicated. There *will* be different dependencies for the client and the server. The server might be masked but the client might work. A concrete example is subversion. The client could be created but not the server (needed apache2) but there was only one ebuild so the package was masked (~x86) and can't make it into a stable gentoo installation. I think it is easier to see that there is a client and a server implementation of an application if the packages are splitted, that is the only thing I really like with RedHat packages. Another thing is that it is very common to have a 'common' package when splitting a package. Example (just a theory): openssh is three packages, openssh-common, openssh-client, openssh-server. where common might install libs etc, client the client part (ssh and sftp) and server the server part (sshd). If I don't want a ssh-server I don't need to compile it. This will be to complicated for the developer of the ebuild to put in one ebuild and for the user to KNOW about this feature for every 'split' package. The USE flag gives me the power to add/remove gtk, qt, X, perl etc feature to application, but if I develop a database application I can't install the mysql lib, and only the lib! All I want to do is "%> emerge mysql-devel" and it will pull in the mysql-common also. If I later decide to install mysql-server I don't need to compile the client and maybe some other parts depending on the build system. USE="client" would not helped me here, I wanted the devel package :) Well, maybe I'm just too borred of having to compile to much stuff all the time... :)
*** Bug 22219 has been marked as a duplicate of this bug. ***
*** Bug 24212 has been marked as a duplicate of this bug. ***
*** Bug 30157 has been marked as a duplicate of this bug. ***
Mabey there could be a more advanced DEPEND system that could parse some files from /var/db/pkg/. If it need to recompile or emrege a new package, it could add server to the USE flag.This would need per-package USE flags. It would then get a different color in emerge -pv <pkg-name>. Perhaps even have a feature flag that will propm the user at the begining of the build, if it is adding a USE flag.
I do not see splitting packages up as very productive (ie, there are more important things to do, and it will require a lot of hacking to not have duplicate compiles). This is for source at least. For binary packages, it might be more possible if portage support a .server.tbz2 and .client.tbz2, as to just specify say two variables that have files specifically just server/client will be easier, and during building packages you usually do it for many boxen, so having both binary packages is not an issue. It will also however increase amount of maintainence needed, something that always loose out (IMHO) if it do not improve stability, but rather have an chance of undermining it.
Also maybe a not on the 'more advance DEPEND system' - _more_advance_ usually means _take_a_lot_longer_ for something like portage's DEPEND system.
Make that: Also maybe a *note* on the 'more advance DEPEND system' - _more_advance_ usually means _take_a_lot_longer_ for something like portage's DEPEND system.
*** Bug 40465 has been marked as a duplicate of this bug. ***
*** Bug 46485 has been marked as a duplicate of this bug. ***
I know this is one of the most favourite topics discussed - what's the status of this actually?
*** Bug 81565 has been marked as a duplicate of this bug. ***
*** Bug 88891 has been marked as a duplicate of this bug. ***
*** Bug 98063 has been marked as a duplicate of this bug. ***
nothing to be done at this point
