On Sat, 10 Jun 2006 02:01:25 +0100 Roy Marples <[EMAIL PROTECTED]> wrote:
> On Saturday 10 June 2006 01:33, Alec Warner wrote: > > > So we have two use flags - client and server. Here are the > > > possabilities > > > > > > -client -server > > > +client -server > > > +client +server > > > -client +server > > > > > > Do we read -client -server and +client +server to mean the same > > > thing? If so the logic can read > > > > > > if use client || ! use server ; then > > > # build client > > > fi > > > if use server || ! use client ; then > > > # build server > > > fi > > > > > > How does portage stop us from doing that now? > > > > built_with_use is then incorrect, since for -client -server you > > really built both. > > use client && build client > use server && build server > > The problem here is that breaks existing ebuilds, which could be > viewed as equally bad. I do think we should avoid built_with_use where we can, as it causes emerge to abort. I still think this would be much better dealt with by splitting the ebuilds and using the existing one to install both sub-ebuilds. To my mind, building client or server is too big a split for USE flags which control features of a package rather than pieces of it. I realise that's not a clear distinction, but I think 'use client|server' is different from 'use ipv6'. The latter, which is how I see most USE flags that build stuff conditionally, is about including support for something within the application/libraries built by the ebuild. However USE client/server is about whether the apps/libraries are built at all. Suggestion was: net-misc/dhcp-client net-misc/dhcp-server net-misc/dhcp - RDEPEND on -client and -server This way, if something needs the server, they depend on dhcp-server. If something needs the client, it depends on dhcp-client. If you need both, depend on net-misc/dhcp. Over time, existing package depedencies can be reduced from dhcp to dhcp-client or dhcp-server as appropriate. The only objection I've seen so far to the split ebuild approach is that if upstream intend the whole tarball to be installed then we should do the same. I don't think that holds too much water; 1) The 'meta' build would provide the complete package as compiled upstream anyway 2) Just because upstream provide everything in one tarball doesn't mean upstream think you should necessarily install everything. Obvious example here is KDE. 3) The use flag approach effectively splits the build anyway, so there's not really any difference. > But technically built_with_use isn't incorrect as the ebuild wasn't > built with it. To effectively use built_with_use you cannot assume > that the flag does what it says on the tin - you have to inspect the > ebuild code you're querying. > > Prior history shows deps of db vs gdbm where if both or neither then > db was used, otherwise the flagged db was used. > > Problems problems - soltutions that work with existing installs or do > we just bite the bullet and do > > ! use client && ! use server && die "must select either client or > server" > > Which kinda defeats the purpose of a clean install. > -- Kevin F. Quinn
signature.asc
Description: PGP signature
