Hi all,
At Tue, 4 Nov 2003 02:18:15 +0100, Marius Mauch wrote:
>
> [1 <text/plain; US-ASCII (7bit)>]
> On 11/03/03 Jason Rhinelander wrote:
>
> > On Mon, 2003-11-03 at 16:17, Donny Davies wrote:
> > > Further, you are overloading the intended function of USE variables.
> > > Instead of controlling optional build-time functionality, now you
> > > are abusing them to control optional install-time bits.
> > >
> > > It is not natural to stop at "client" and "server" flags either.
> > > What about "dev" for .a and .h things? This is really going down
> > > the slipperly slope in my opinion.
> >
> > Not to mention the fact that you could easily want the MySQL server &
> > client, but only the Samba client. Does this mean you'd have to have
> > "mysqlserver", "sambaclient", "sambadoc", etc. USE flags? Or would
> > you juggle around with your use flags for various packages, preventing
> > you from being able to emerge -u world? This is actually a greater
> > problem- per-package USE flags would be wonderfully USEful (pardon the
> > pun) in many other situations.
>
> That's bug 13616, to be included in portage-2.0.50.
>
> > The only logical way I can see to do this is splitting everything up
> > into multiple packages, i.e. mysql-server mysql-client, mysql-docs,
> > samba-server, samba-client, samba-docs, etc. - and I really dislike
> > that approach (I'm against the vim-core/vim/gvim split as well), for
> > the reasons mentioned above (and the fact that "updating portage
> > cache" after an emerge sync takes long enough as is without shattering
> > packages 7 or 8 ways each).
>
> There are several reasons why I'm against package splits:
> - redundant code: most times the ebuilds for the subpackages will be
> very similar
> - maintenance: if a new version is out you have to update n packages
> instead of one, if there is a new bug you to fix it in all packages
> - space overhead: the portage tree has about 80% filesystem overhead for
> most people, coming from a lot of small files (digests, Manifests,
> metadata.xml). Each new package makes this worse.
> - slower portage: the more packages we have the slower portage will be.
> One package won't do much, but a few hundred new packages can make a
> noticable difference.
I do not think server or client (or doc in some way) fits well in USE
flags either, so i was thinking of another way to parametrize ebuilds.
Why not add a new variable for ebuilds that could be set when you
use a particular extra name. My idea is:
in samba-*.ebuild:
FLAVORS="client server"
src_compile () {
flavor client && ...
}
Then if you emerge samba you get all flavors, if samba-1.2#client then
only client and common code etc...
There would be virtually 3 packages but only one file, which could avoid
much of the problems you mention.
Just my 0.02 (euro) cents.
--
Matthieu Sozeau
www: http://mattam.ath.cx
--
[EMAIL PROTECTED] mailing list
