Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Monday 12 June 2006 08:23, Chris Gianelloni wrote: On Sat, 2006-06-10 at 19:56 -0400, Mike Frysinger wrote: On Saturday 10 June 2006 10:29, Chris Gianelloni wrote: On Fri, 2006-06-09 at 18:34 -0400, Mike Frysinger wrote: On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. rather than moving to some sort of policy that satisfies no one completely and we'll have to back out of later, why dont we wait until portage can give us proper support for USE=client/server Got an ETA? The situation we have now is confusing, at best, to our users, and something really should be done to resolve it. sure, dont add support for the flags at all at this point, problem solved You apparently missed that there already are packages in the tree using these flags, as well as minimal. not really ... i'm fully aware of USE=server since ive used it myself USE=client however doesnt exist, so you'd be incorrect there This inconsistent usage is what I was trying to solve in the first place. with a stop gap measure ... i dont think this stop gap effort is worth the extra time, especially since it'll be simply backed out of down the road -mike pgpMPLCpqCra8.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
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
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Saturday 10 June 2006 09:32, Kevin F. Quinn wrote: Suggestion was: net-misc/dhcp-client net-misc/dhcp-server net-misc/dhcp - RDEPEND on -client and -server You would also need net-misc/dhcp-common then to stop client and server installing the same required libraries and headers. In this instance, keeping it in one ebuild outweights the advantage of a split ebuild in my eyes. 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. I doubt any package will ever depend on a dhcp server as such so that helps the one ebuild argument. I think I'll keep it as it now is - minimal use flag stops server installation. -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Friday 09 June 2006 21:27, Ned Ludd wrote: Maybe along the same lines as what you are pointing out here it should also be noted that built_with_use is semi faulty and can return wrong results when no /var/db/pkg/$CATEGORY/$PVR/USE exists. this is done on purpose -mike pgpkeT3VMXksr.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Saturday 10 June 2006 04:32, Kevin F. Quinn wrote: I do think we should avoid built_with_use where we can, as it causes emerge to abort. no it doesnt ... the ebuild maintainer makes the package abort based upon the results of built_with_use ... -mike pgpIaYYFHjNYa.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
Chris Gianelloni wrote: On Fri, 2006-06-09 at 22:05 +0100, Stuart Herbert wrote: On 6/9/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Gentoo's standard operating procedure is to build packages as they were intended and packaged from upstream. +1 This means if the client and the server for a particular package is in a single package, we should build both by default. No thanks. That doesn't match the standard operating procedure mentioned above. By default, why don't we just build whatever $UPSTREAM intended built by default? That is *exactly* what I said. It means that different packages will behave differently throughout the tree, but that's okay, and is more Gentoo-like than your proposal. Except that you're just saying exactly what I said, just in different words. To facilitate building the client portions only, the use of the local minimal USE flag is allowed. How will you support building the server-only portions of the package? I honestly never bothered to consider it, and really don't care. Someone else can come up with that idea. The problem with using two USE flags is what do you do when someone chooses neither? It will build the $UPSTREAM default? And btw, i like the server and client use flag idea. +1 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Sat, 10 Jun 2006 05:44:41 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Saturday 10 June 2006 04:32, Kevin F. Quinn wrote: I do think we should avoid built_with_use where we can, as it causes emerge to abort. no it doesnt ... the ebuild maintainer makes the package abort based upon the results of built_with_use ... well yeah, that's what I meant :P -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Fri, 2006-06-09 at 18:34 -0400, Mike Frysinger wrote: On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. rather than moving to some sort of policy that satisfies no one completely and we'll have to back out of later, why dont we wait until portage can give us proper support for USE=client/server Got an ETA? The situation we have now is confusing, at best, to our users, and something really should be done to resolve it. Waiting another 6 months to a year, only to be able to use it with the particular portage versions that support the proper EAPI for use-based dependencies is not an optimal answer for our users, which is why I came up with the proposal. Honestly, I don't care *what* is decided, so much as I want to spark conversation and see *some* resolution come of it that is *at least* consistent until use-based dependencies are a reality. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Sat, 2006-06-10 at 01:24 +0100, Roy Marples wrote: Do we read -client -server and +client +server to mean the same thing? We could, yes. 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? It doesn't. The problem comes in with the dependency resolver. The only solution to this is checks using built_with_use in pkg_setup, which is discouraged except where absolutely necessary, as it causes all of the dependencies to be merged (incorrectly, possibly) before there is a failure. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Saturday 10 June 2006 10:29, Chris Gianelloni wrote: On Fri, 2006-06-09 at 18:34 -0400, Mike Frysinger wrote: On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. rather than moving to some sort of policy that satisfies no one completely and we'll have to back out of later, why dont we wait until portage can give us proper support for USE=client/server Got an ETA? The situation we have now is confusing, at best, to our users, and something really should be done to resolve it. sure, dont add support for the flags at all at this point, problem solved USE=minimal has no real definition, no point in trying to iron one out imo -mike pgpKXsIMY6zIf.pgp Description: PGP signature
[gentoo-dev] [RFC] client/server policy for ebuilds
This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. The idea is quite simple. Gentoo's standard operating procedure is to build packages as they were intended and packaged from upstream. This means if the client and the server for a particular package is in a single package, we should build both by default. To facilitate building the client portions only, the use of the local minimal USE flag is allowed. This can be shown in the openldap and dhcp ebuilds. Each package which uses this flag should document what is built when the minimal USE flag is in use, via use.local.desc as it will remove any ambiguity into what is being done. Because of this, I would request that minimal not become a global USE flag, since its meaning would actually be different between some packages, for example, minimal in xorg-server, that causes it to only build the primary server, and not the secondary servers, such as DMX. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On 6/9/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Gentoo's standard operating procedure is to build packages as they were intended and packaged from upstream. +1 This means if the client and the server for a particular package is in a single package, we should build both by default. No thanks. That doesn't match the standard operating procedure mentioned above. By default, why don't we just build whatever $UPSTREAM intended built by default? It means that different packages will behave differently throughout the tree, but that's okay, and is more Gentoo-like than your proposal. To facilitate building the client portions only, the use of the local minimal USE flag is allowed. How will you support building the server-only portions of the package? I don't want clients I don't need on my servers. client and server USE flags would appear to make much more sense here (for packages that have any such clear distinction), and will play better when USE-based DEPs become reality. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Fri, 2006-06-09 at 22:05 +0100, Stuart Herbert wrote: On 6/9/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Gentoo's standard operating procedure is to build packages as they were intended and packaged from upstream. +1 This means if the client and the server for a particular package is in a single package, we should build both by default. No thanks. That doesn't match the standard operating procedure mentioned above. By default, why don't we just build whatever $UPSTREAM intended built by default? That is *exactly* what I said. It means that different packages will behave differently throughout the tree, but that's okay, and is more Gentoo-like than your proposal. Except that you're just saying exactly what I said, just in different words. To facilitate building the client portions only, the use of the local minimal USE flag is allowed. How will you support building the server-only portions of the package? I honestly never bothered to consider it, and really don't care. Someone else can come up with that idea. The problem with using two USE flags is what do you do when someone chooses neither? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Fri, 2006-06-09 at 16:35 -0400, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. The idea is quite simple. Gentoo's standard operating procedure is to build packages as they were intended and packaged from upstream. This means if the client and the server for a particular package is in a single package, we should build both by default. To facilitate building the client portions only, the use of the local minimal USE flag is allowed. This can be shown in the openldap and dhcp ebuilds. That is backwards however. The first ebuild to take advantage of building server/client was net-snmp and it uses minimal to build only the snmpd, snmptrapd. Sense then others have been bastardizing the USE flag. Being that net-snmp was historically first in doing this I'd rather not have to change all my setups on all my servers to accommodate your idea of inverting the logic of declaring it minimal to mean client-only. Each package which uses this flag should document what is built when the minimal USE flag is in use, via use.local.desc as it will remove any ambiguity into what is being done. Because of this, I would request that minimal not become a global USE flag, since its meaning would actually be different between some packages, Seems logical. But for what you are proposing I'd suggest not making USE of minimal at all for this. I'd rather see that flag reserved for mostly embedded alike use. -peace -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. rather than moving to some sort of policy that satisfies no one completely and we'll have to back out of later, why dont we wait until portage can give us proper support for USE=client/server -mike pgpW7HbKAYULr.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Fri, Jun 09, 2006 at 06:19:53PM -0400, Ned Ludd wrote: Seems logical. But for what you are proposing I'd suggest not making USE of minimal at all for this. I'd rather see that flag reserved for mostly embedded alike use. Me too. A server/client set of USE flags seems more appropriate to me. Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpwzLLFM0rG6.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
Mike Frysinger wrote: rather than moving to some sort of policy that satisfies no one completely and we'll have to back out of later, why dont we wait until portage can give us proper support for USE=client/server -mike +1 -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Friday 09 June 2006 23:34, Mike Frysinger wrote: On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. rather than moving to some sort of policy that satisfies no one completely and we'll have to back out of later, why dont we wait until portage can give us proper support for USE=client/server -mike 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? -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
Roy Marples wrote: On Friday 09 June 2006 23:34, Mike Frysinger wrote: On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. rather than moving to some sort of policy that satisfies no one completely and we'll have to back out of later, why dont we wait until portage can give us proper support for USE=client/server -mike 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
How does portage stop us from doing that now? I don't think it does ... but you'll have to go back and clean it up when USE-based DEPs support eventually arrives. But we can worry about that nearer the time. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
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. 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. -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Sat, 2006-06-10 at 02:01 +0100, Roy Marples 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. 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. Maybe along the same lines as what you are pointing out here it should also be noted that built_with_use is semi faulty and can return wrong results when no /var/db/pkg/$CATEGORY/$PVR/USE exists. This happens when using the most recent ppc-uclibc stages which omitted a few entries from the vdb. We end up having some ebuild or other assuming that uclibc itself was built with +nls when it's really (-nls) use.masked etc.. Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
