| 1 |
On Sat, 10 Jun 2006 02:01:25 +0100 |
| 2 |
Roy Marples <uberlord@g.o> wrote: |
| 3 |
|
| 4 |
> On Saturday 10 June 2006 01:33, Alec Warner wrote: |
| 5 |
> > > So we have two use flags - client and server. Here are the |
| 6 |
> > > possabilities |
| 7 |
> > > |
| 8 |
> > > -client -server |
| 9 |
> > > +client -server |
| 10 |
> > > +client +server |
| 11 |
> > > -client +server |
| 12 |
> > > |
| 13 |
> > > Do we read -client -server and +client +server to mean the same |
| 14 |
> > > thing? If so the logic can read |
| 15 |
> > > |
| 16 |
> > > if use client || ! use server ; then |
| 17 |
> > > # build client |
| 18 |
> > > fi |
| 19 |
> > > if use server || ! use client ; then |
| 20 |
> > > # build server |
| 21 |
> > > fi |
| 22 |
> > > |
| 23 |
> > > How does portage stop us from doing that now? |
| 24 |
> > |
| 25 |
> > built_with_use is then incorrect, since for -client -server you |
| 26 |
> > really built both. |
| 27 |
> |
| 28 |
> use client && build client |
| 29 |
> use server && build server |
| 30 |
> |
| 31 |
> The problem here is that breaks existing ebuilds, which could be |
| 32 |
> viewed as equally bad. |
| 33 |
|
| 34 |
I do think we should avoid built_with_use where we can, as it causes |
| 35 |
emerge to abort. |
| 36 |
|
| 37 |
I still think this would be much better dealt with by splitting the |
| 38 |
ebuilds and using the existing one to install both sub-ebuilds. |
| 39 |
To my mind, building client or server is too big a split for USE flags |
| 40 |
which control features of a package rather than pieces of it. I realise |
| 41 |
that's not a clear distinction, but I think 'use client|server' is |
| 42 |
different from 'use ipv6'. The latter, which is how I see most USE |
| 43 |
flags that build stuff conditionally, is about including support for |
| 44 |
something within the application/libraries built by the ebuild. |
| 45 |
However USE client/server is about whether the apps/libraries are built |
| 46 |
at all. |
| 47 |
|
| 48 |
Suggestion was: |
| 49 |
net-misc/dhcp-client |
| 50 |
net-misc/dhcp-server |
| 51 |
net-misc/dhcp - RDEPEND on -client and -server |
| 52 |
|
| 53 |
This way, if something needs the server, they depend on dhcp-server. |
| 54 |
If something needs the client, it depends on dhcp-client. If you need |
| 55 |
both, depend on net-misc/dhcp. Over time, existing package depedencies |
| 56 |
can be reduced from dhcp to dhcp-client or dhcp-server as appropriate. |
| 57 |
|
| 58 |
The only objection I've seen so far to the split ebuild approach is that |
| 59 |
if upstream intend the whole tarball to be installed then we should do |
| 60 |
the same. I don't think that holds too much water; |
| 61 |
|
| 62 |
1) The 'meta' build would provide the complete package as compiled |
| 63 |
upstream anyway |
| 64 |
|
| 65 |
2) Just because upstream provide everything in one tarball doesn't mean |
| 66 |
upstream think you should necessarily install everything. Obvious |
| 67 |
example here is KDE. |
| 68 |
|
| 69 |
3) The use flag approach effectively splits the build anyway, so |
| 70 |
there's not really any difference. |
| 71 |
|
| 72 |
> But technically built_with_use isn't incorrect as the ebuild wasn't |
| 73 |
> built with it. To effectively use built_with_use you cannot assume |
| 74 |
> that the flag does what it says on the tin - you have to inspect the |
| 75 |
> ebuild code you're querying. |
| 76 |
> |
| 77 |
> Prior history shows deps of db vs gdbm where if both or neither then |
| 78 |
> db was used, otherwise the flagged db was used. |
| 79 |
> |
| 80 |
> Problems problems - soltutions that work with existing installs or do |
| 81 |
> we just bite the bullet and do |
| 82 |
> |
| 83 |
> ! use client && ! use server && die "must select either client or |
| 84 |
> server" |
| 85 |
> |
| 86 |
> Which kinda defeats the purpose of a clean install. |
| 87 |
> |
| 88 |
|
| 89 |
|
| 90 |
-- |
| 91 |
Kevin F. Quinn |
Archives