Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
Use INSTALL_MASK to keep /usr/bin/mysqld or whatever from getting installed. We aren't generally in the habit of splitting packages into a bunch of different ebuilds. There are exceptions, but --Iggy Christian Parpart wrote: Hi all, well, regarding the request on bug 88490 [1] (and my own needs) I'm in a deep problem ;) There *are* packages out there, that depend on (networking) client libraries (and their headers of course); for the general mysql ebuild, I'd propose the following splitup: * dev-db/mysql-server (or myssqld) * net-libs/libmysqlclient * dev-db/mysql (a meta package that simply depends on both, for backward compat) The reason is, that some packages need to talk to (SQL )servers, but some host installation do not need - or even want to (think about security policies) - a local (SQL) server; Using the minimal useflag for this - IMHO - is a misuse of the idea of minimal semantically - as I do understand minimal in a way like don't overbloat me with patches and other feature additions-alike. This idea of course is applicable for lots of more packages, but mysql is one use case where I myself ran into; Do we have a general accepted gentoo policy for this? And... any thoughts on this subject? Regards, Christian Parpart. [1] http://bugs.gentoo.org/show_bug.cgi?id=88490 -- I top post... suck it -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
Mike Frysinger wrote: On Thursday 18 August 2005 10:28 am, Christian Parpart wrote: Do we have a general accepted gentoo policy for this? general policy is to not split packages (and i agree with this ...) bind and bind-tools is split ;) Why is it so bad to split packages? (I'm just curious) Seems a bit odd that we can't have a library only, client only, etc package like the other distros. Of course, I understand that we could use useflags for that, but is that really the best solution for this particular issue? Oh well, I'm just a sysadmin, not a coder so I'll got back to my cave. ;) -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Thu, 18 Aug 2005 10:13:33 -0500 Lance Albertson [EMAIL PROTECTED] wrote: | bind and bind-tools is split ;) Why is it so bad to split packages? | (I'm just curious) Seems a bit odd that we can't have a library only, | client only, etc package like the other distros. Of course, I | understand that we could use useflags for that, but is that really | the best solution for this particular issue? We can't use USE flags because portage won't let us. There's been a bug open about USE deps for yess. Plus, the other issue... Say your package depends upon mysql, then someone comes along and splits mysql via USE flags. You'll then need to update your package to depend upon, say, mysql[client] because the default behaviour will be to not require any particular USE flag to be enabled. TGL had a rather interesting proposal regarding 'parts', which are similar to USE flags but the default behaviour is to depend upon a package with all parts enabled unless explicitly indicated otherwise. You may wish to find it and flesh it out some more. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpieZl0NLQhL.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
Luca Barbato wrote: Christian Parpart wrote: Using the minimal useflag for this - IMHO - is a misuse of the idea of minimal semantically - as I do understand minimal in a way like don't overbloat me with patches and other feature additions-alike. minimal is about keeping the package at the minimum, that means strip every feature that won't prevent it to run. Maybe it's foggy for mysql usage, better suggestions (clientonly, libonly) ? Do we have a general accepted gentoo policy for this? Usually the policy is If the upstream has planned that we'll follow, otherwise no [IMHO] Upstream distribuite binaryes of only libraryes, in this direction it's supported. Build them from the source only libs is not deeply supported, see below. [/IMHO] And... any thoughts on this subject? I'd prefer to have those features enabled by useflag, sometimes (eg. qemu) I can split functionality in separated ebuild and use a metaebuild to let users merge both w/out major overhead. In your case a useflag IMHO would be enough since the situation require a particular setup and in the case the constraint changes won't be a problem rebuild a full mysql. The question is, does the mysql configure script have a clientonly and/or a libraryonly option? there is an option for configure --without-server , but actually the server is still build. Take a look at = dev-db/mysql-4.0.24-r2 for how minimal use flag is used, basically it force some flag off and remove some files from the install. There were a client and server useflag discussion before. lu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote:
2) ebuild maintenance will be a nightmare- every new version will
require again walking the source to see if the lines you've drawn for
dividing the source are still proper.
This is another good point. I have two split packages that I maintain.
They are ut2004{,-data,-bonuspack-ece} and kudzu/libkudzu. In my case,
the distinctions are actually quite easy, as ut2004-data pulls from the
CD, ECE pulls from a distfile (or the CD, with lots of detection-fu),
and ut2004 is an actual package of the latest patch files, not a
meta-package. As for kudzu/libkudzu, the kudzu Makefile already has
this distinction built-in, so I don't have to maintain it myself.
I'd see no problem with this in mysql, if, for example, mysql's Makefile
had a make libmysqlclient target. In that case, I would make it a
separate package. This would also mean a lot of work on your part, as
every single package that had a dependency on mysql would now need some
way of specifying whether the server was going to be local or remote, to
properly *DEPEND on the correct package.
All in all, I think it isn't worth even attempting at this time.
Short version, control what gets installed via use flags, but don't
introduce it until use deps are available in a stable portage.
Breaking the beast up now is short sighted since use deps are
already implemented in the core rewrite. Yes, waiting is a pain in
the ass, but the work to break it up and continue to indefinitely
force subpackaging on an package isn't worth it.
Agreed.
--
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
Lance Albertson wrote: Mike Frysinger wrote: On Thursday 18 August 2005 10:28 am, Christian Parpart wrote: Do we have a general accepted gentoo policy for this? general policy is to not split packages (and i agree with this ...) bind and bind-tools is split ;) Why is it so bad to split packages? (I'm just curious) Seems a bit odd that we can't have a library only, client only, etc package like the other distros. Of course, I understand that we could use useflags for that, but is that really the best solution for this particular issue? Oh well, I'm just a sysadmin, not a coder so I'll got back to my cave. ;) vimdiff bind-tools/bind-tools-9.2.5.ebuild bind/bind-9.2.5-r5.ebuild In the eventuality of mysql being splitted the landscape is totally different. The code to duplicate is a 40% of the ebuild speaking of volume, in maintenance the percentage is bigger. I'm a (little) sysadmin too, redundancy is good speaking of servers but maintain a cluster or simply to synced servers is more difficult (and error prone) that maintain only one, right ? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Thu, Aug 18, 2005 at 11:37:05AM -0400, Chris Gianelloni wrote: Other distributions are also binary-only, so there's no real comparison here. While I think having client and server type USE-flags is really a bad idea, I don't see a problem with providing a library. I 100% disagree with splitting the package into client and server, but don't think it would be bad to have it like this: net-libs/libmysqlclient dev-db/mysql You'll notice that there is no server package. The dev-db mysql package should be the entire distribution. Splitting out a separate library for client-only shouldn't be too bad, but I still disagree with it, for the most part. Splitting it out is just as bad as breaking it into server/client chunks from the added QA and maintenance standpoint, thing is, in this case splitting out the lib *is* breaking it up into subpackages, so it's no better :) Best solution in my opinon? Two use flags address this, client, and server. Regardless of the setting of the two, you get the library; from there, you just set client and server as defaulting to on, and packages use dep on whatever chunk of it they need (quite likely no use dep in this case, since they probably only need the lib). Better tweak to it is not the usual use.defaults addition, but specifying the default state of the USE flag in IUSE, as proposed by spanky/others. Kind of curious about people's opinion on the IUSE default use flag thing, initial syntax was (using the above example) IUSE=+client server with client defaulting to on unless the user's config disables it- note, strictly enabling from IUSE, no auto-negation. I forgot to add this, but it's a 10 line change if people still view it as worthwhile. ~harring pgp2ePYxRLr1q.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Thu, 18 Aug 2005 10:56:06 -0500 Brian Harring [EMAIL PROTECTED] wrote: | Best solution in my opinon? Two use flags address this, client, and | server. Regardless of the setting of the two, you get the library; | from there, you just set client and server as defaulting to on, and | packages use dep on whatever chunk of it they need (quite likely no | use dep in this case, since they probably only need the lib). We went over this already. We can't have client and server USE flags because the meaning is totally different for every package. Plus the 'probably' really isn't good enough, since there are some packages that have more specific dependency and the current die in pkg_setup stuff is a real pain -- do we really want to see that becoming a regular occurrence? -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpQLOMIm09gg.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Thu, Aug 18, 2005 at 06:24:03PM +0100, Ciaran McCreesh wrote: On Thu, 18 Aug 2005 10:56:06 -0500 Brian Harring [EMAIL PROTECTED] wrote: | Best solution in my opinon? Two use flags address this, client, and | server. Regardless of the setting of the two, you get the library; | from there, you just set client and server as defaulting to on, and | packages use dep on whatever chunk of it they need (quite likely no | use dep in this case, since they probably only need the lib). We went over this already. Englighten me, since the issues I'm groking from this I'm fairly sure I already stated/covered :) We can't have client and server USE flags because the meaning is totally different for every package. Plus the 'probably' really isn't good enough, since there are some packages that have more specific dependency and the current die in pkg_setup stuff is a real pain -- do we really want to see that becoming a regular occurrence? You're a bit vague in the 'die in pkg_setup' bit; if you're referencing doing the changes now, and sticking a die in, I already explicitly stated the responsible party would need a wedgie if it was done; the lets check for use flags on our deps in pkg_setup is evil as hell, and *only* should be used when absolutely explicitly required. iow, wait for use deps unless you've got some damn good reason to fall back to the kludge while waiting. Other angle I see is if you're referencing naming the vars in mutually exclusive use flags; if that's the case, I'll just point out that the use flag names in the suggested solution aren't mutually exclusive. Re: probably, it's a comment on the packages that depend on mysql; will they 'probably' require the library (meaning no use dep with the flag configuration above), or will they require the client and/or server chunks (requiring use flags on). Not advocating loose depends if that's how you read it, just added bonus for most packages that dep on mysql that it's use configuration wouldn't require use deps. We can't have client and server USE flags because the meaning is totally different for every package. Meh, I disagree without counter examples provided of where client/server breaks down as a global use flag :) Either way, in this case it *does* make sense, and going with any *only style route makes the flags mutually exclusive (bad). So the alternative names would have to be...? One comment on mutually exclusive use flags/confutils bit- I've asked before and never gotten a decent response, but I'd like to see mutually exclusive use flags represented somehow in an ebuild- preferably a seperate metadata key, and probably requiring the addition of an xor operator to dep syntax. Pretty much just represent the conflicts, and what flags are dependant on one another. Bit ambivalent about that latter part however, since I gtk/gtk2 interaction is a sore point in the tree from where I'm sit. ~harring pgpS67k6LlDzV.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Fri, Aug 19, 2005 at 01:06:35AM +0100, Ciaran McCreesh wrote: On Thu, 18 Aug 2005 13:13:56 -0500 Brian Harring [EMAIL PROTECTED] wrote: | You're a bit vague in the 'die in pkg_setup' bit; if you're | referencing doing the changes now, and sticking a die in, I already | explicitly stated the responsible party would need a wedgie if it was | done; the lets check for use flags on our deps in pkg_setup is evil | as hell, and *only* should be used when absolutely explicitly | required. iow, wait for use deps unless you've got some damn good | reason to fall back to the kludge while waiting. For how many years have we been waiting for USE deps? I'd say that this discussion is pretty much pointless. In the distant future when we do get USE deps we'll no doubt have a whole different set of issues to figure out. USE deps have been sitting in core rewrite's cvs since monday. ~harring pgpEp8FM2N59y.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Thursday 18 August 2005 19:01, Georgi Georgiev wrote: maillog: 18/08/2005-16:28:40(+0200): Christian Parpart types Using the minimal useflag for this - IMHO - is a misuse of the idea of minimal semantically - as I do understand minimal in a way like don't overbloat me with patches and other feature additions-alike. minimal - Install a very minimal build (disables, for example, plugins, fonts, most drivers, non-critical features) vanilla - Do not add extra patches which change default behaviour I agree with these definitions. however, why I was refering to the minimal use-flag anyway, was, because comment 1 in the bug-report statet, that we *do* have the minimal use-flag to achieve, what the bug-reporter was intending to get (a splitout of client-only libs/headers); Extract of comment 1 in the bug: | New ebuilds have the minimal use flag. This flag build the server with | configure --without-server . | explaining better this last point. You still need to download ALL the | package from MySQL site *BUT* only the libraries will be installed. They reason for why I was ever intending to ask here on -dev and why I'm CCed in the bug still is: * it looks a little overbloated, when you wanna install cat/foo ebuild that supports to back its data to mySQL instead of sqlite, and you *have* to install a server for that (not always); this might be irrelevant for desktop machines, but the hell not for servers; you can't predict, that you maintain INSTALL_MASK-alike var to prevent such things being installed. you (in first place) do not know what you all need to mask anyway * a useflag (so I use and understand them) are for enabling features or other *extra* advantages (like kdeenablefinal or debug); * while having not taken a look at the mysql build side, I don't believe, that it would be an overhead in splitting out libmysqlclient (and that's what we're finally talking about) and making (for backwards compatibility and use) it a depend to the already existing dev-db/mysql package; Regards, Christian Parpart. -- 04:26:38 up 148 days, 17:34, 1 user, load average: 0.86, 1.39, 1.97 pgpmHlNUu3Czy.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Thursday 18 August 2005 17:44, Chris Gianelloni wrote: On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote: 2) ebuild maintenance will be a nightmare- every new version will require again walking the source to see if the lines you've drawn for dividing the source are still proper. minimize the duplication by a mysql eclass, just like we do for apache e.g. (and lots of others) that prevent us from code duplication. I'd see no problem with this in mysql, if, for example, mysql's Makefile had a make libmysqlclient target. In that case, I would make it a separate package. Having a look at the already provided libmysqlclient ebuild [1] it obviousely (and for our luck) looks like upstream supports this installation types. This would also mean a lot of work on your part, as every single package that had a dependency on mysql would now need some way of specifying whether the server was going to be local or remote, to properly *DEPEND on the correct package. We've plenty of tools that help us in searching for all ebuilds *directly* depending on dev-db/mysql; than you just need to decide, wether this needs the server or not. And (w/o looking at them) I do predict, that 100% of them will only need libmysqlclient. Why? What package would depend on the server in particular? If the user wants the server to be run on localhost, than he would just have to add it to his emerge args as well. I see no problems there - instead: it would be a great enheancement. (IMO) All in all, I think it isn't worth even attempting at this time. read above. do you still think so? If so, why? Regards, Christian Parpart. [1] http://bugs.gentoo.org/attachment.cgi?id=55816 -- 04:43:52 up 148 days, 17:51, 1 user, load average: 0.66, 0.76, 1.15 pgpojzr28kw9N.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Thursday 18 August 2005 17:01, Georgi Georgiev wrote: vanilla - Do not add extra patches which change default behaviour For features, I would expect individual USE flags-- what if I want one patch, but not another? For changing mere defaults, a gentoo USE flag seems like it would make sense. -- Luke-Jr Developer, Utopios http://utopios.org/ pgpiM8sSu5CQb.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
On Fri, Aug 19, 2005 at 05:30:42AM +0200, Christian Parpart wrote: On Thursday 18 August 2005 17:44, Chris Gianelloni wrote: On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote: 2) ebuild maintenance will be a nightmare- every new version will require again walking the source to see if the lines you've drawn for dividing the source are still proper. minimize the duplication by a mysql eclass, just like we do for apache e.g. (and lots of others) that prevent us from code duplication. Point was you would have to inspect each release to ensure it still fits. If upstream does this for you, it's not any more of an issue then normal QA. Yes this is being anal (re: the verification), but it's proper QA ultimately. I'd see no problem with this in mysql, if, for example, mysql's Makefile had a make libmysqlclient target. In that case, I would make it a separate package. Having a look at the already provided libmysqlclient ebuild [1] it obviousely (and for our luck) looks like upstream supports this installation types. Multiple configure/builds required- also is worth verifying that building the client/server against the lib does just that, uses existing on disk lib rather then rebuilding. Why? What package would depend on the server in particular? If the user wants the server to be run on localhost, than he would just have to add it to his emerge args as well. I see no problems there - instead: it would be a great enheancement. (IMO) All in all, I think it isn't worth even attempting at this time. read above. do you still think so? If so, why? Increased configuration run time per upgrades, two packages two maintain; why is that an issue? 1) dev-db/mysql must dep on the matching lib version. $PV address this, mostly. 2) 2 packages to handle in p.mask and for doing keywording changes 3) 2 packages to handle at the user side of things for keywording/masking. Real strong points I'm sure; key thing about all of this is that it's increased A) work, B) manual steps required (read: points of screwup). All of the args come down to that, extra complexity/work. If I saw mysql as being loosely bound between it's server and lib components, I'd think it was good to potential chunk into two packages. I don't, obviously. Use conditionals exist *exactly* for user choice like this (iow you've got the tools already to keep it contained as one). That's honestly the strongest arg I can make; the limiting factor is that you're stuck waiting since use dep's aren't available yet. ~harring pgpLZt9RKYQVt.pgp Description: PGP signature
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
maillog: 19/08/2005-02:59:46(+): Luke-Jr types On Thursday 18 August 2005 17:01, Georgi Georgiev wrote: vanilla - Do not add extra patches which change default behaviour For features, I would expect individual USE flags-- what if I want one patch, but not another? I agree. Fine-grained control is nice, but I also like the idea of being able to refuse all non-upstream patches that change default behaviour. Similarly to what mutt is doing: !vanilla? ( nntp? ( ) some other patches that have no useflag ) For changing mere defaults, a gentoo USE flag seems like it would make sense. -- \Georgi Georgiev \ Alcoholics Anonymous is when you get to \ /[EMAIL PROTECTED] / drink under someone else's name. / \ +81(90)2877-8845 \ \ pgpX20TBZKZ5r.pgp Description: PGP signature
