Re: [gentoo-dev] SLOTed MySQL or not?
On Wed, Mar 01, 2006 at 11:28:32AM +, Francesco Riosa wrote: Before to this to happen I'll try my best to close the greatest number of bugs still open (many already are but not committed) and manage to bring MySQL back to the unslotted version. [1] Yes. 12% [ 12 ] No. 75% [ 72 ] No preference. 11% [ 11 ] I have one question: Who answer NO on poll? As for me slotted version of mysql is better for hosting companies. I can present to client anothers versions of mysql: 4.1 and 5.0 for example In php.ini for client i only change the port where mysql php module connected and client have 5.0 for example, but others client have 4.1 as default. I think it's have reason. -- WBR, Alexander Simonov (DEVL-UANIC) Ukrainian Gentoo Community Coordinator -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Mike Frysinger wrote: On Wednesday 01 March 2006 21:53, Mark Loeser wrote: Here is my updated version after some feedback from people: * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations. * In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council. one thing i dont think we give enough emphasis to is that our tools arent perfect ... sometimes we utilize QA violations to work around portage limitations ... if you want to see some really sweet hacks, review any of the toolchain related ebuilds and the hacks ive had to add to get cross-compiling to the usuable state that it is today. a handful of them would fall under the 'severe' category i'm sure. and if we want to use the lovely php example, personally i think that given portage's current limitations, the latest dev-lang/php ebuild is probably one of the best solutions that could have been developed, thanks Stuart for all the flak you've had to take over this. also, many games ebuilds break the 'non-interactive' policy by displaying licensing and making the user hit Y because portage lacks checks where the user explicitly states what licenses they accept. -mike I installed dev-lang/php on a server in my house to test torrents.gentoo.org and ramereth also installed it on the torrents.g.o server. I have to say that it was a painless and normal operation with no errors. Thanks for the hard work on this ebuild, it's appreciated. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] enable UTF8 per default?
On Wed, Mar 01, 2006 at 01:24:26AM +0900, Kalin KOZHUHAROV wrote: Well there are a few problems, but yes I cannot name them now. Using Japanese, Cyrillic and English in a few encodings each is a big nightmare. It's true! We in xUSSR use KOI8-R, KOI8-U, CP1251 ( aka Windows-1251), CP866. Nowadays I try to move everything to UTF-8, but there are those windoze users and webdevs that make all Japanese in Shift_JIS ... So support of wide range of encodings is a must, but UTF-8 is the truth. The only thing that's nasty: we don't have any good utf8-fonts for the console. And not only the console. Even for xterm there are not many good fonts (known to me) that display both Japanese and Cyrillic in regular and bold. Currently there is only on combination that works for me. What about terminus and UniCyr (unicode font from console-tools-cyrillic)? I am use this fonts and most of russian speaking people says what this font is the best font for cyrilic charsets. I am don't see any issues in fonts for me. So fonts, font config and related stuff is what has to be fixed first. -- WBR, Alexander Simonov (DEVL-UANIC) Ukrainian Gentoo Community Coordinator -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Fri, 3 Mar 2006 22:44:22 +, Stuart Herbert [EMAIL PROTECTED] wrote: Unless a user looks inside the ebuild, they're not going to understand why the USE flags they've selected has resulted in a package that doesn't actually have those features. ... This is going to *create* more support, not reduce it. The problem here, from a user point of view, is the USE flag usage not matching its description (that's what makes unexpected the ebuild behavior). For instance, description says foo - Enable libfoo, whereas actually the ebuild will only use libfoo if some other bar is unset. One point of view on this issues is that the ebuilds are wrong, because they are abusing the said USE flags, and they should rather die. Imho, it makes sense, but if such a strict policy was applied to every ebuilds which atm are abusing flags this way, it would become really hard to put anything in the make.conf USE variable without breaking emerge -uD world. Just take the default flags from x86 profile for instance: both motif (Adds motif support) and gtk (Adds support for x11-libs/gtk+) are enabled, whereas the logic in several packages supporting both is to build the GTK interface when gtk is on, and to build a Motif one otherwise, if motif is on. Do you think such ebuilds should rather die at compile time, asking the user to make an unconflicting choice? I don't. My package.use is already ~200 lines long for various other reasons, and i really don't want to double its size again just to make my emerge -uD world successfully terminating. Now, an alternative point of view is that what is wrong is rather the USE flag descriptions. That's exactly what the package specific USE flag descriptions proposal, which popups on this list from time to time, is about (sorry, no URL because GMane seems down, but i can post some later if you're interested). The idea (or at least my pov on this idea, but others had different views iirc) is that emerge could display some package-specific flags descriptions in such cases. Using the emerge patch from bug #84884, and with a use.local.desc entry for app-editors/gvim:motif, the user would be warned about what the motif flag actualy does (or does not) on this package: --- % emerge -pv --use-desc-special gvim ... [ebuild R ] app-editors/gvim-6.4 USE=-acl bash-completion cscope gnome gpm gtk motif nls -perl python ruby 0kB ... The following USE flags have package-specific descriptions: app-editors/gvim motif - Include support for the Motif GUI, but if gtk or gnome flags are turned on too, in which case they are prefered. --- This way, nothing unexpected for users, and no complain for devs. -- TGL. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Friday 03 March 2006 23:32, Grant Goodyear wrote: Stuart Herbert wrote: I agree. Adopting a policy like this is a low quality solution for servers. I've no opinion on how this affects desktops, but packages for servers need to be precise.A policy that says if two USE flags deliver the same benefits, but conflict, pick one is fine. But saying flip a coin ... how on earth is that quality? See my previous post. And how the heck is it going to work w/ USE-based defaults? This creates a situation where package (b) cannot trust that a feature is enabled in package (a), even if package (a) was built with the required USE flags. Yep. Having a USE flag enabled turns out not to be a guarantee. That said, package builds do become deterministic, so (for example) if one needs to know if msmtp was built with openssl or gnutls it is easy enough to pull the logic from the msmtp ebuild. I'm sure that there is a more elegant solution, but I'm not convinced that having the user randomly throw USE flags at a package until some combination works is necessarily it. I could be wrong, however. *Shrug* You mean the logic should be replicated between msmtp and all packages that need to know how it was built. I see this as a bigger source of bugs (msmtp changes, some of the dependants forget to change too) than verifying at setup time that the package has sane use flags. I'd prefer that a stage were introduced that runs at pretend time exactly for these things. I would say it is a bug if a useflag was specified for a package, including dependencies, and the package does not actually depend on it because the useflag was not actually applied. But even if the dependencies are proper, it is a bug from a HCI point of view. A package should deliver what it promisses. If it can't it should fail, not silently ignore the request. Until Portage supports resolving conflicting USE flags when the deptree is built, the practical thing to do is for ebuilds w/ conflicting USE flags to bail. I, quite respectfully, disagree. As explained above, when an ebuild can not deliver, it should fail, not silently downgrade its features. Especially when other packages may depend on those features being present. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpgvlRFCHTSr.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Saturday 04 March 2006 00:29, Ciaran McCreesh wrote: On Fri, 3 Mar 2006 23:14:41 + Stuart Herbert [EMAIL PROTECTED] wrote: | If we're going to do this, then at least we should be implementing a | consistent standard across all ebuilds. F.ex, when SSL and TLS | conflict, we should have a standard saying that all ebuilds will | consistenly favour one over the other. That's much more deterministic | than having some ebuilds prefer SSL, and others prefer TLS (for | example). And what of gtk vs qt, where for many packages one is clearly the preferred choice, but which one this is varies between packages? Do *you* know which GUI is the best option for gvim and why? Than say in the policy For the choice TLS vs SSL choose SSL. For the choice GTK vs QT choose the upstream preferred; if there is none, choose QT (Don't pin me on the choices in this example) Heck, it's hard enough figuring out a usable set of USE flags for PHP. If we started dieing for the three zillion or so mutually independent GUI options in gvim7 users would never actually be able to figure out how to install the thing... The problem is that these flags are dependent. Bailing out on independent useflags is not needed. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpBYCzBkJJo0.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
Hi Thomas,
Am Samstag, 4. März 2006 14:24 schrieb Thomas de Grenier de Latour:
One point of view on this issues is that the ebuilds are wrong, because
they are abusing the said USE flags, and they should rather die. Imho,
it makes sense, but if such a strict policy was applied to every
ebuilds which atm are abusing flags this way, it would become really
hard to put anything in the make.conf USE variable without breaking
emerge -uD world.
Just to throw in my 2 cents into this discussion: I'm all against die-ing
during the update process. However, i think that stopping before the update
process would be the best solution at hand. I'd like to propose the addition
of a dedicated USE conflict detection to ebuilds which need it.
This detection function (for example pkg_prepare()) must be executed for every
package in the depgraph right after the depgraph has been built and has only
the possibility to either mark the package as 'go' or 'no-go'. In case that
any package has been marked as 'no-go', the whole process stops.
A possible implementation from the build side could look like this:
# the next two functions would be candidates for eutils.eclass
emutexuse() {
eerror The following USE flags are mutually exclusive:
eerror [EMAIL PROTECTED]
eerror Please choose only one of the above and disable the remaining
eerror USE flags. For additional information about this problem, see
eerror http://www.gentoo.org/some place to store add. info about
this
echo
}
emissinguse() {
eerror In order to enable the ${2} USE flag you need also to enable
eerror the ${1} USE flag. For additional information
echo
}
pkg_prepare() {
local ret=0
if use foo use bar ; then
emutexuse foo bar
ret=1
fi
if use fnord2 ! use fnord ; then
emissinguse fnord fnord2
ret=1
fi
return ${ret}
}
Comments?
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Hi Ciaran, On 3/3/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: And what of gtk vs qt, where for many packages one is clearly the preferred choice, but which one this is varies between packages? Do *you* know which GUI is the best option for gvim and why? No, I don't. But that doesn't mean the user shouldn't make the choice. Even if it is the wrong one from your point of view with your additional knowledge. We're a metadistribution, not a distribution. We're supposed to be all about allowing the user to tailor each and every package to his/her exact specification. I think the policy of 'never die' would be understandable for a distribution, but I don't feel it's appropriate for a metadistribution. Heck, it's hard enough figuring out a usable set of USE flags for PHP. How so? We've worked very hard to ensure that's not the case. What have we missed? Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Hi Mike, On 3/4/06, Mike Frysinger [EMAIL PROTECTED] wrote: bad idea ... Yes it is a bad idea; policy belongs with users. It shouldn't be hardcoded into ebuilds, whether across the whole tree or per package. But ... I realise I'm flogging a dead horse here. We'll come up with a new revision of the PHP packages which builds *something* no matter how broken the combination of USE flags are. We'll test it first in our overlay, and then when we're happy we'll add them to the tree for testing and eventual stabilisation. We'll also provide a replacement for 'built_with_use', which works with what the package was actually compiled with, rather than what USE flags the user originally specified. This will be needed for all the web-based apps that are written in PHP. That might take a bit longer, and might have to follow in a later revision. As already pointed out, all this will have to be revisited when Portage supports USE-based deps. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)
Hi Ciaran, On 3/4/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: Explanation: a USE flag for trivial stuff that isn't in /etc, doesn't slow anything down, doesn't introduce any dep bloat and generally doesn't change anything noticeable isn't a USE flag that's giving the user any meaningful choice or making things easier for arch teams. You do not get bonus points for using more USE flags. Another point of view are servers, where there's simply no need to have docs installed on each and every box in a rack. There's no need to install what a user doesn't need, and having doc and example USE flags more widely supported means that Gentoo does a better job of respecting the choice of users. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Hi Danny, On 3/4/06, Danny van Dyk [EMAIL PROTECTED] wrote: Just to throw in my 2 cents into this discussion: I'm all against die-ing during the update process. However, i think that stopping before the update process would be the best solution at hand. I'd like to propose the addition of a dedicated USE conflict detection to ebuilds which need it. This is the sort of thing we're asking for in bug #75936. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)
On Saturday 04 March 2006 17:15, Stuart Herbert wrote: Hi Ciaran, On 3/4/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: Explanation: a USE flag for trivial stuff that isn't in /etc, doesn't slow anything down, doesn't introduce any dep bloat and generally doesn't change anything noticeable isn't a USE flag that's giving the user any meaningful choice or making things easier for arch teams. You do not get bonus points for using more USE flags. Another point of view are servers, where there's simply no need to have docs installed on each and every box in a rack. There's no need to install what a user doesn't need, and having doc and example USE flags more widely supported means that Gentoo does a better job of respecting the choice of users. I agree with Ciaran. IMO the convenience of having docs outweighs the modest amount of diskspace/clutter they need (average of 50 MB on my average server, when then rest of the installed packages take at least an order of magnitude more). If you're concerned about diskspace you can filter out /usr/share/doc entirely, so users do have the choice. The problem here is that the docs USE flag is off by default. Making more packages use the flag would install less docs. Has anyone actually complained that too many docs are installed by default? It's true that some users/situations don't need them, but most do, especially as long as we don't have separate server profiles. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgpIPKO8ctnLh.pgp Description: PGP signature
[gentoo-dev] Re: Gratuitous useflaggery (doc and examples)
Stuart Herbert wrote: Another point of view are servers, where there's simply no need to have docs installed on each and every box in a rack. There's no need to install what a user doesn't need, and having doc and example USE flags more widely supported means that Gentoo does a better job of respecting the choice of users. Amen. I use FEATURES=noinfo noman nodoc and USE=-doc on all of my server installs. My only desire is that there would be a way to turn them off more completely - no texinfo, no perl man page generation, etc... I would also like to have them excluded from binary packages. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)
On Saturday 04 March 2006 16:43, Dan Armak wrote: If you're concerned about diskspace you can filter out /usr/share/doc entirely, so users do have the choice. The problem here is that the docs USE flag is off by default. Making more packages use the flag would install less docs. Has anyone actually complained that too many docs are installed by default? It's true that some users/situations don't need them, but most do, especially as long as we don't have separate server profiles. I have seen quite a few bugs about that and actually have filed one¹, rotting in bugzilla, myself. I definitely do not care about a few hundred KB documentation per ebuild, but some install a lot of documentation and accumulated it's a lot of wasted space. Filtering out /usr/share/doc as a whole is no choice, when you usually want it, but a fair share not. Carsten [1] https://bugs.gentoo.org/show_bug.cgi?id=116658 pgpTtLTWWm7nr.pgp Description: PGP signature
Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)
On Saturday 04 March 2006 02:04, Ciaran McCreesh wrote: This is undocumented and unofficial, so feel free to utterly ignore it and commit whatever the heck you want. The 'doc' and 'examples' (yay for consistency!) Don't now, if I guess right what you want to say, but there's no plural of documentation afaik. ;p Carsten pgpJVcckIIBPO.pgp Description: PGP signature
Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)
On Sat, Mar 04, 2006 at 05:43:22PM +0200, Dan Armak wrote: Has anyone actually complained that too many docs are installed by default? Don't know about docs, but if examples count here too, see bug #111508. pgpWPL45zC4Dq.pgp Description: PGP signature
[gentoo-dev] Re: Gratuitous useflaggery (doc and examples)
Stuart Herbert posted [EMAIL PROTECTED], excerpted below, on Sat, 04 Mar 2006 15:15:30 +: On 3/4/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: Explanation: a USE flag for trivial stuff that isn't in /etc, doesn't slow anything down, doesn't introduce any dep bloat and generally doesn't change anything noticeable isn't a USE flag that's giving the user any meaningful choice or making things easier for arch teams. You do not get bonus points for using more USE flags. Another point of view are servers, where there's simply no need to have docs installed on each and every box in a rack. There's no need to install what a user doesn't need, and having doc and example USE flags more widely supported means that Gentoo does a better job of respecting the choice of users. You are correct -- a server doesn't need all that stuff, and indeed, shouldn't have it, particularly examples, as that's just more stuff that might be exploitable in some way. However, the standard answer there is that users should use INSTALL_MASK for docs and examples and the like on servers. That's more dependable than a USE flag that may or may not be there, and leaves the USE flags for the egregious cases, as Ciaran suggested, thus effectively giving the user a tri-state control instead of forcing a binary-state control where it doesn't really fit. (Note that INSTALL_MASK files are still created, so someone INSTALL_MASKING will want to negate the appropriate USE flags as well, to avoid the non-trivial merge-time processing case.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Gratuitous useflaggery (doc and examples)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 4 Mar 2006, MIkey wrote: Stuart Herbert wrote: Another point of view are servers, where there's simply no need to have docs installed on each and every box in a rack. There's no need to install what a user doesn't need, and having doc and example USE flags more widely supported means that Gentoo does a better job of respecting the choice of users. Amen. I use FEATURES=noinfo noman nodoc and USE=-doc on all of my server installs. My only desire is that there would be a way to turn them off more completely - no texinfo, no perl man page generation, etc... I would also like to have them excluded from binary packages. That can't be right can it? You mean, like openoffice-bin, or like the ones you build yourself? I know that I often build on one system, install on several, and when I do that, I really want them to be identical. I think if you have your no-docs-of-any-kind option, you get your wish as to locally built packages, but if you really mean things like openoffice-bin, I doubt that any openoffice user would want it with absolutely no documentation. Confused, Ferris - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFECcg1Qa6M3+I///cRAisAAKCnE4JMHq+wze8+Ghy6MEUtEyWqYACgqF1e xy3lX0ZeBC6D5GraVIXbM0E= =c9G5 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Gratuitous useflaggery (doc and examples)
On Sat, 04 Mar 2006 12:04:11 -0600 MIkey [EMAIL PROTECTED] wrote: | At my job we aim to eventually rid ourselves completely of MS | products on several thousand (local and remote) desktops and replace | them with some sort of thin linux client running the citrix metaframe | client. They will be running in kiosk mode. No user will have the | ability to get to a window manager and browse around | in /usr/share/doc. They don't even know what the heck a man page is. Then you should use INSTALL_MASK, not a USE flag. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Gratuitous useflaggery (doc and examples)
On Saturday 04 March 2006 18:00, Carsten Lohrke wrote: On Saturday 04 March 2006 16:43, Dan Armak wrote: If you're concerned about diskspace you can filter out /usr/share/doc entirely, so users do have the choice. The problem here is that the docs USE flag is off by default. Making more packages use the flag would install less docs. Has anyone actually complained that too many docs are installed by default? It's true that some users/situations don't need them, but most do, especially as long as we don't have separate server profiles. I have seen quite a few bugs about that and actually have filed one¹, rotting in bugzilla, myself. I definitely do not care about a few hundred KB documentation per ebuild, but some install a lot of documentation and accumulated it's a lot of wasted space. Filtering out /usr/share/doc as a whole is no choice, when you usually want it, but a fair share not. I agree that really large docs should be made USE-dependant. This is also consistent with Ciaran's orig post. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 pgp89TMpeXkxd.pgp Description: PGP signature
[gentoo-dev] Re: Re: Re: Gratuitous useflaggery (doc and examples)
Ciaran McCreesh wrote: On Sat, 04 Mar 2006 12:04:11 -0600 MIkey [EMAIL PROTECTED] wrote: | At my job we aim to eventually rid ourselves completely of MS | products on several thousand (local and remote) desktops and replace | them with some sort of thin linux client running the citrix metaframe | client. They will be running in kiosk mode. No user will have the | ability to get to a window manager and browse around | in /usr/share/doc. They don't even know what the heck a man page is. Then you should use INSTALL_MASK, not a USE flag. Please excuse my ignorance, but what the heck is INSTALL_MASK and where is it documented? Can it exclude things from being included in binary packages? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Gratuitous useflaggery (doc and examples)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 4 Mar 2006, MIkey wrote: Ferris McCormick wrote: I misinterpreted what you wrote. I thought you meant physically included in the package, not installed from a binary package. I just completely read what looks like a reasonable request and turned it into nonsense without thinking about it, I guess. I am not so sure you misinterpreted me, because when I specify -doc and emerge -B a package, I don't want docs installed OR in the binary package that is generated. I want the behavior of USE flags to be consistent. If I set -ssl and generate a binary package for apache2, the packaged up libraries should not link with ssl libraries. The same should apply with -doc. That happens now, I believe. The following should all install the same thing: USE='-doc' emergeblah USE='-doc' emerge -b blah USE='-doc' emerge -B blah ; emerge -k blah USE='-doc' emerge blah; quickpkg blah; emerge -C blah; emerge -k blah Assuming all dependencies are satisfied. (The binary package is built from the image which is going to be installed and carries the USE flags with it. If the docs aren't there, they're not there. Or at least, the binary package carries the '-doc' use flag along with it so the docs won't be installed.) What won't install the same is this sequence: USE='doc' emerge -B blah USE='-doc' emerge -k blah 'emerge -k' uses the USE flags the package was built with. Example: Back to ciaranm's original proposal. If I USE='-doc' emerge -B xorg-x11 I am never going to be able to decide I wanted USE='doc' after all and pull the docs from the binary package. Documentation for xorg-x11 is in a separate source file, and with USE='-doc', that file is never even fetched. So, USE='doc' emerge -k xorg-x11 cannot install docs. Concrete example (from a live system): emerge -pkv rubygems [binary R ] dev-ruby/rubygems-0.8.11 USE=-examples USE='examples' emerge -pkv rubygems [binary R ] dev-ruby/rubygems-0.8.11 USE=-examples Or am I still missing something? What I would really like is the same capability with info and man pages. Currently the only way to exclude them is use the unsupported, undocumented FEATURES=noman noinfo hack, which if I am not mistaken does not remove them from binary packages. Try a du -ksh /usr/share/doc /usr/share/man /usr/share/info and you might get an idea of why the feature might be desirable: 132M/usr/share/doc 5.7M/usr/share/info 56M /usr/share/man Most of those are compressed, which means they take even _more_ space in a binary package. It adds up. Regards, Ferris - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFECfz8Qa6M3+I///cRAnqrAKDj5ZhOlKKt5MWnqpEZlReUad8CnwCfQDbu vAQJZ2Lzi8hnOqLMfL8Rc68= =48Q+ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Re: Gratuitous useflaggery (doc and examples)
MIkey posted [EMAIL PROTECTED], excerpted below, on Sat, 04 Mar 2006 12:18:22 -0600: Ciaran McCreesh wrote: On Sat, 04 Mar 2006 12:04:11 -0600 MIkey [EMAIL PROTECTED] wrote: | At my job we aim to eventually rid ourselves completely of MS | products on several thousand (local and remote) desktops and replace | them with some sort of thin linux client running the citrix metaframe | client. They will be running in kiosk mode. No user will have the | ability to get to a window manager and browse around | in /usr/share/doc. They don't even know what the heck a man page is. Then you should use INSTALL_MASK, not a USE flag. Please excuse my ignorance, but what the heck is INSTALL_MASK and where is it documented? Can it exclude things from being included in binary packages? INSTALL_MASK is similar to the CONFIG_PROTECT and CONFIG_PROTECT_MASK portage variables in that it takes a list of directories (or files, wildcarding is acceptable), settable in make.conf. portage will still package those files in binary packages, but won't install anything that matches INSTALL_MASK. Thus, you can stick /usr/doc and /usr/share/doc in it, and snag anything that would be installed to them. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Gratuitous useflaggery (doc and examples)
On Sat, 04 Mar 2006 12:18:22 -0600,
MIkey [EMAIL PROTECTED] wrote:
Can it exclude things from being included in binary packages?
AFAIK, no. But what you could use (with portage-2.1) is a hook
function in /etc/portage/bashrc:
post_src_install() { rm -rf ${D}usr/share/doc ; }
This way, files will be deleted for real, before getting merged or
added to your binary package.
--
TGL.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Gratuitous useflaggery (doc and examples)
Thomas de Grenier de Latour wrote:
post_src_install() { rm -rf ${D}usr/share/doc ; }
This way, files will be deleted for real, before getting merged or
added to your binary package.
No, that function never gets executed with binary packages. You probably meant
post_pkg_preinst.
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 Member
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Gratuitous useflaggery (doc and examples)
On Sat, 04 Mar 2006 23:04:22 +0100,
Simon Stelling [EMAIL PROTECTED] wrote:
Thomas de Grenier de Latour wrote:
post_src_install() { rm -rf ${D}usr/share/doc ; }
This way, files will be deleted for real, before getting merged or
added to your binary package.
No, that function never gets executed with binary packages.
I know, but what i understand from MIkey's email is that he wants to
create some smaller binary packages, without the doc files inside.
Hence the choice of post_src_install.
If it was to do it at pre/post_pkg_preinst time, then INSTALL_MASK
would have done the trick anyway, no need for a hook function.
--
TGL.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Danny van Dyk [EMAIL PROTECTED] said: Just to throw in my 2 cents into this discussion: I'm all against die-ing during the update process. However, i think that stopping before the update process would be the best solution at hand. I'd like to propose the addition of a dedicated USE conflict detection to ebuilds which need it. This detection function (for example pkg_prepare()) must be executed for every package in the depgraph right after the depgraph has been built and has only the possibility to either mark the package as 'go' or 'no-go'. In case that any package has been marked as 'no-go', the whole process stops. I'd rather see the ebuild marked with some flag to show there are conflicting use flags that have been resolved, and by adding --verbose or some other flag, you can see what flags are overridden so the user knows exactly what is going on, and can decide if they like the defaults the ebuild developer has chosen. I think we should give users the choice/information to make an informed decision, but I don't think we should shove a failure into their lap when we can make choices for them which we believe to be sane. I'd like less errors/dies during the build/deptree phase and more warnings/information to be presented so the user could look at it and make changes, or just accept what we have done for them. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpuYYiCyv87J.pgp Description: PGP signature
Re: [gentoo-dev] svk maintainer needed
kang wrote: [Thu Nov 03 2005, 02:29:11PM EST] I can maintain it if no one else can. Feel free. I've bumped the version once and added a patch, but I would rather not be the primary maintainer. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp2uMipSEbc5.pgp Description: PGP signature
[gentoo-dev] xemacs herd and maintainer
It looks like xemacs is currently in need of maintainers. The herd is currently nonexistent and there is no one on the alias. There are a number of bugs open about xemacs: http://tinyurl.com/makfd I'm not sure how we currently handle such a situation, but I personally think we should mask all of the packages if no maintainer can be found to step up. So, is anyone willing to do so? -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpKwJdtfJuDe.pgp Description: PGP signature
