[gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
В Пнд, 27/06/2011 в 17:01 +0200, Fabian Groffen пишет:
On 27-06-2011 14:08:52 +, Justin Lecher wrote:
Please do not use / as seperater when using sed with CFLAGS. I came
across a bug today where it failed for crossdev. Here the toolchain
header paths in the cflags and consowuently the seds fail.
This is already documented (see link below).
Please also don't use ':' as separator, as some platforms have options
for their toolchain that includes colons.
But still our documentation explicitly suggests ':' for CFLAGS cases and
example allows bash substitution.
http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/building/index.html
see example in Fixing Compiler Usage section and text below:
sed -i -e s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}: build.sh
Are there any objections to suggest '|' for CFLAGS, LDFLAGS (see
attachment)?
--
Peter.
From 989cd3700ec0f3aa13cfca08b97c4c461b738883 Mon Sep 17 00:00:00 2001
From: Peter Volkov p...@gentoo.org
Date: Tue, 28 Jun 2011 10:05:17 +0400
Subject: [PATCH] Use | as a separator for sed'ing CFLAGS
/, : is a bad idea per thread on gentoo-dev:
http://archives.gentoo.org/gentoo-dev/msg_654cd9daf2548a524c8a09a82b80916f.xml
---
.../functions/src_compile/building/text.xml|8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/ebuild-writing/functions/src_compile/building/text.xml b/ebuild-writing/functions/src_compile/building/text.xml
index 700f0f1..550ef5c 100644
--- a/ebuild-writing/functions/src_compile/building/text.xml
+++ b/ebuild-writing/functions/src_compile/building/text.xml
@@ -58,15 +58,17 @@ src_compile() {
# We have a weird build.sh to work with which ignores our
# compiler preferences. yay!
-sed -i -e s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}: build.sh \
+sed -i -e s|cc -O2|$(tc-getCC) ${CFLAGS} ${LDFLAGS}| build.sh \
|| die sed fix failed. Uh-oh...
./build.sh || die Build failed!
}
/codesample
note
-When using csed/c with cCFLAGS/c or cLDFLAGS/c, it is not safe to use
-a comma or a slash as a delimiter. The recommended character is a colon.
+When using csed/c with cCFLAGS/c or cLDFLAGS/c, it is not safe to
+use a comma, a colon or a slash as a delimiter. cgcc/c options may contain
+this characters so csed/c will fail after bash expansion. The recommended
+character is a vertical bar: '|' (the pipe).
/note
p
--
1.7.3.4
Re: [gentoo-dev] Re: Thoughts about broken package handling
On Tue, 28 Jun 2011 16:54:43 +1200 Kent Fredric kentfred...@gmail.com wrote: Reminds me of the other awkward behaviour I once hit where a package depends on something that is slotted, and mysteriously uses a middle version of the things that are slotted, and then breaks with that version that it for some mysterious reason found a preference for, and upon removing that particular version of the slot, it uses the most recent slotted version instead, and then works perfectly. There was going to be a really simple, elegant, ebuild-controllable and provably working fix for that in EAPI 4 in the form of := deps, but they got dropped because Portage couldn't implement it. Which is strange, because it should have been a ten minute job... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Are tags just sets?
On Mon, 27 Jun 2011 16:23:54 -0400 Rich Freeman ri...@gentoo.org wrote: Sets should really be something carefully controlled by the repository. While I'm fine with having tags in the repository also, there is talk about giving users ways of supplying them as well. Why? You can have carefully controlled sets for fancy things. But tag sets don't need to be carefully controlled. The way you give users control over tags using sets is to make sets in overlays be merged with sets with the same name in the main tree, and then allow users who feel like it to publish an overlay containing their tags. Here is how I see tags being used: 1. I want a WYSIWYG html editor. 2. I search for tags like editor and html and WYSIWYG and maybe even text. 3. I check out descriptions and homepages or whatever for a few likely candidates, and install one or maybe two. $package_mangler search-tags editor html wysywig What I doubt I'd ever do is just install any package that has anything to do with text/html editing. Not really a problem. Sets are usable for lots of things, not just installing. They're useful in configuration files, for example -- you'd probably never want to install every X driver either, but you might want to set some options for every X driver. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Are tags just sets?
On Mon, 27 Jun 2011 20:21:29 +0200 Maciej Mrozowski reave...@gmail.com wrote: The problems with PROPERTIES=set remain exactly the same as they were when it was first proposed. Which is? No, been there, done that, won't work is not sufficient. Please elaborate. You can find and read the original discussion as well as I can. No point in going over exactly the same material all over again since the design hasn't been updated since. Uh, I don't see how that's in any way difficult to maintain. No, it's not difficult, it's pain in ass to keep a hundred files with a few thousands lines each up2date with tree changes (pkgmove, cvs remove). Yes, it could be automated by some crafty cvs hook on server. However cvs hooks should be the last resort and not a tool to deal with consequences of broken design. If that were true, you'd be doing the same thing for package.mask... *shrug* If you really think it's that bad, though, go with Brian's proposal, and whilst you're at it, make package.mask and all those other profile files that contain long lists of package names be created the same way. Tag is a property or attribute of package That one's highly debatable. It's not debatable for those familiar with object oriented design concept. Clearly it is. Have a look at posts in this thread. Some people insist that tags are properties of ebuilds, some that they're properties of packages, some that they're repository-level properties, and some that they're external, user-level properties. For that matter, ebuilds aren't object oriented. Good, so you'll be happy going with what Unix has been using for decades then. Indeed, with sets in bash (ebuild) format. No point, just like there's no point in package.mask being an ebuild. Depends upon what you think the tags concept is. We've already established that everyone has a different idea of what tags are anyway. I don't know what's everyone's idea behind the tag, I refer to: http://en.wikipedia.org/wiki/Tag_(metadata) Sure, and that's sufficiently vague that all sorts of completely different ideas could be called tags. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
On 28-06-2011 10:16:06 +0400, Peter Volkov wrote: Are there any objections to suggest '|' for CFLAGS, LDFLAGS (see attachment)? Not from my side. It's what we've been using so far. note -When using csed/c with cCFLAGS/c or cLDFLAGS/c, it is not safe to use -a comma or a slash as a delimiter. The recommended character is a colon. +When using csed/c with cCFLAGS/c or cLDFLAGS/c, it is not safe to +use a comma, a colon or a slash as a delimiter. cgcc/c options may contain gcc - gcc, ld, ar, etc. +this characters so csed/c will fail after bash expansion. The recommended +character is a vertical bar: '|' (the pipe). -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
On Tue, 28 Jun 2011 10:16:06 +0400
Peter Volkov p...@gentoo.org wrote:
But still our documentation explicitly suggests ':' for CFLAGS cases
and example allows bash substitution.
http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/building/index.html
see example in Fixing Compiler Usage section and text below:
sed -i -e s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}: build.sh
Are there any objections to suggest '|' for CFLAGS, LDFLAGS (see
attachment)?
I think that also a good idea may be to provide an Makefile example,
showing that often sed is unnecessary, and it's enough to do things
like:
emake CC=$(tc-getCC) CFLAGS=${CFLAGS}...
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] The Python problem
On Mon, 27 Jun 2011 16:49:23 -0400 Mike Frysinger vap...@gentoo.org wrote: if you dont want multiple builds on your system, then dont install multiple versions of python. -mike This would be nice, but unfortunately the python maintainer forced 3.x on everyone, despite the fact that nothing uses it and no one really wanted it made the default. So now it's shipped with all the stage tarballs, in addition to 2.7. You've got it whether you want it or not. This is one of the things that needs to be rescinded, along with the python eclass changes. Get everyone down to just one version of python installed. signature.asc Description: PGP signature
Re: [gentoo-dev] The Python problem
On Tue, Jun 28, 2011 at 08:54, Joshua Saddler nightmo...@gentoo.org wrote: This would be nice, but unfortunately the python maintainer forced 3.x on everyone, despite the fact that nothing uses it and no one really wanted it made the default. So now it's shipped with all the stage tarballs, in addition to 2.7. You've got it whether you want it or not. This is one of the things that needs to be rescinded, along with the python eclass changes. Get everyone down to just one version of python installed. It's just slotting like everything else. (There's an open bug for the stages.) Cheers, Dirkjan
Re: [gentoo-dev] The Python problem
On Mon, Jun 27, 2011 at 20:23, Benedikt Böhm hol...@gentoo.org wrote: the way python applications are built currently renders all binary packages useless, since portage does not know which version of python it was built against. the explicit selection with RUBY_TARGETS or PHP_TARGETS solves this problem at the small cost of commiting new values to these variables from time to time. I don't think updating all Python packages every two years is a small cost, particularly when a large percentage of those packages will just work on the new version. (Another problem with the current Ruby approach is that it's impossible to support unstable interpreters or versions from in stable package versions, such that Ruby packages now often have multiple ebuild revisions for stable and unstable interpreters.) Cheers, Dirkjan
Re: [gentoo-dev] The Python problem
On Mon, Jun 27, 2011 at 21:31, Michał Górny mgo...@gentoo.org wrote: Working targets. USE_PYTHON is junk. What python.eclass does now with ABIs is a PITA, and requires manually providing a lot of redudant information (namely, RESTRICT_PYTHON_ABIS). Please clarify *why* it is a PITA, and what information is redundant. Right now, each ebuild has to provide the same information in PYTHON_DEPEND and RESTRICT_PYTHON_ABIS. Moreover, if an ebuild supports, say, py3 and its dependency doesn't, the ebuild has to restrict py3 too. I'll grant you that PYTHON_DEPEND and RESTRICT_PYTHON_ABIS seem redundant, we could probably fix that. I'd like to see that fixed somehow. I'd like to set a single supported Python version information in an ebuild, and let the dependency resolver handle everything else. That would be bad; it's common and useful to have packages installed in both 2.6 and 2.7 (and even 3.1). Cheers, Dirkjan
Re: [gentoo-dev] The Python problem
On Mon, Jun 27, 2011 at 22:46, Petteri Räty betelge...@gentoo.org wrote: Sure, but if that means the developers now have to bump every package in the tree when a new version of Python comes out, I'm not sure that's the best trade-off. And why can't this be handled by the eclass? If the ebuild is able to specify it supports =3.0 meaning it's expected that future versions work then the eclass can make the new values available through IUSE when new python versions are out and ebuilds don't require any changes. I'd be happy to get that to work, it seems like a good solution. Cheers, Dirkjan
[gentoo-dev] Re: REMOVE
Stelios Boulios posted on Tue, 28 Jun 2011 09:51:41 +0300 as excerpted: [blank, see subject] See the headers for any post forwarded by this list. They all contain the following information: List-Post: mailto:gentoo-dev@lists.gentoo.org List-Help: mailto:gentoo-dev+h...@lists.gentoo.org List-Unsubscribe: mailto:gentoo-dev+unsubscr...@lists.gentoo.org List-Subscribe: mailto:gentoo-dev+subscr...@lists.gentoo.org List-Id: Gentoo Linux mail gentoo-dev.gentoo.org It would appear that you want to mail the address in List-Unsubscribe (you missed the +unsubscribe bit). Be sure to watch for the confirming unsubscribe mail and confirm it as required. -- 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
Re: [gentoo-dev] The Python problem
On Tue, 28 Jun 2011 10:04:58 +0200 Dirkjan Ochtman d...@gentoo.org wrote: On Mon, Jun 27, 2011 at 21:31, Michał Górny mgo...@gentoo.org wrote: Working targets. USE_PYTHON is junk. What python.eclass does now with ABIs is a PITA, and requires manually providing a lot of redudant information (namely, RESTRICT_PYTHON_ABIS). Please clarify *why* it is a PITA, and what information is redundant. Let's put it like that. I have package foo which support py2 and py3. It depends on package bar which once supported py3 but the newest version is known to be broken with py3, and thus breaks building my package as well. And right now there's no real way to handle that dependency. With SLOT-USEdeps I could do 'bar[py3=]'. With current state of Python eclass I have to restrict ABIs to match newer version and/or restrict dependency versions which is awfully redundant. I'd like to see that fixed somehow. I'd like to set a single supported Python version information in an ebuild, and let the dependency resolver handle everything else. That would be bad; it's common and useful to have packages installed in both 2.6 and 2.7 (and even 3.1). I think you misunderstood me. I mean generating the whole dependency tree from support Python versions. Like dropping version info from PYTHON_DEPEND in favor of RESTRICT_PYTHON_ABIS. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] ldconfig symlink updates -- do we need that?
Hello, As you may or may not know, right now env-update calls 'ldconfig' by default, describing that in the terms of 'Regenerating /etc/ld.so.cache'. In fact, it does a little more -- it updates library symlinks to use the newest library version available. In other words, if we've got libfoo.so.1.1 and .1.2 with the same SONAME, and libfoo.so.1 symlinks to .1.1, ldconfig would replace that by a symlink to .1.2. This seems to be the major cause of the problems with portage's preserve-libs feature. When a package is downgraded, portage replaces the SONAME symlink with an older version to make newly-built packages use that older version, and preserves the newer libraries not to break linkage. But a short while later, ldconfig takes over the symlink and makes it point to the newer version once again. Packages still link to the newer version and the only way to get the library actually downgraded is to remove the preserved library. Thus, it's even worse than without preserved-libs. On the other hand, that ldconfig behavior seems completely redundant as packages are installed with .so symlinks anyway. And I think that if package manager installs those symlinks, it should manage them itself instead of letting external tools mangle with PM-installed files. I have created a patch which makes 'env-update' always pass '-X' to ldconfig, to not let it update the symlinks in system-wide libdirs. I'm testing it right now to see if it doesn't cause any breakage. If that causes problems (i.e. some packages don't actually create correct .so symlinks themselves), I guess we could decide to call 'ldconfig -N -n' in post-install operations, like the deprecated 'preplib' helper does. This way, the symlinks will be completely controlled by the Package Manager and the preserve-libs feature should handle downgrades just fine. And I've just downgraded libav, and rebuilt mplayer2 against it with the newer version being preserved just fine. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] ldconfig symlink updates -- do we need that?
On Tue, 28 Jun 2011 10:48:48 +0200 Michał Górny mgo...@gentoo.org wrote: I have created a patch which makes 'env-update' always pass '-X' to ldconfig, to not let it update the symlinks in system-wide libdirs. I'm testing it right now to see if it doesn't cause any breakage. And, as always, forgot to attach it. Here it goes. -- Best regards, Michał Górny From 268d114e90cf3d20a816e194a5d8711e65060983 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= mgo...@gentoo.org Date: Tue, 28 Jun 2011 10:10:36 +0200 Subject: [PATCH] Don't ever recreate root .so links on env-update. We install .so symlinks with packages, so let's use that instead of letting ldconfig update them for no reason. This should fix problems with preserved-libs. --- man/env-update.1 |3 +-- pym/portage/util/env_update.py |5 + 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/pym/portage/util/env_update.py b/pym/portage/util/env_update.py index a89f2e2..a82afdf 100644 --- a/pym/portage/util/env_update.py +++ b/pym/portage/util/env_update.py @@ -248,10 +248,7 @@ def env_update(makelinks=1, target_root=None, prev_mtimes=None, contents=None, # we can safely create links. writemsg_level(_( Regenerating %setc/ld.so.cache...\n) % \ (target_root,)) - if makelinks: -os.system(cd / ; %s -r '%s' % (ldconfig, target_root)) - else: -os.system(cd / ; %s -X -r '%s' % (ldconfig, target_root)) + os.system(cd / ; %s -X -r '%s' % (ldconfig, target_root)) elif ostype in (FreeBSD,DragonFly): writemsg_level(_( Regenerating %svar/run/ld-elf.so.hints...\n) % \ target_root) -- 1.7.6 signature.asc Description: PGP signature
Re: [gentoo-dev] Are tags just sets?
On Tue, Jun 28, 2011 at 03:43:21PM +1200, Kent Fredric wrote: A. Storing tag data in metadata.xml ( package - tag association ) B. Developing a tool that aggregates the contents of metadata.xml to produce a cache for the data going the other way ( tag - package ) People searching for packages that match a tag will thusly be able to read this cached data ( Our primary use case ) and people who want to know what tags a specific package have will read/augment metadata.xml I Believe both these parts are required for the design to be successful. However, both parts have a bit of bike-shedding involved in them, part A of the system requires changes to exisiting structures, and part A requires bike shedding about part B's format. For the sake of simplicity, I'm ( and I believe others ) are simply suggesting we develop part B first. It's sub hour or so to look at the existing `egencache --update-use-local-desc` (specifically GenUseLocalDesc class) and implement such a cache. It's not hard. Either way, if you want this, the part that will take time is integrating it into emerge itself for searching; now if you want to write that code twice, go nuts, but someone lazier would do both at the same time to make sure they structured the API so it could support in one pass, rather than deploying an API, than having to shoehorn the cpv argument in. If people want it, cut a patch and post it for feedback either way- bearing in mind that from where I'm sitting, deploying it half-assed requiring people to maintain a bunch of text files isn't a viable option ;) ~brian
[gentoo-dev] RFC: optinal run time dependencies
Hi guys. We've had discussion on optional runtime dependencies in bug 361255, but I think it's worth to have broader discussion of this issue. = Abstract Optional runtime dependencies are dependent packages that are not required to run program but when installed enhance program run-time features. Below new use flag prefix is suggested to handle such rdeps. Motivation Optional run time dependencies are packages that are not required at runtime but when installed provide additional features for program. For example, app-text/asciidoc works fine without media-gfx/graphviz, but to generate diagrams from a textual specification media-gfx/graphviz have to be installed. Currently there are two common approaches for this problem: 1. add a use flag to control runtime dependency 2. add elog message into pkg_postinst to notify users that some features depend on installing package A, B, etc. Both of this approaches are suboptimal. Use-flags (1) will require user to rebuild package just to install optional runtime dependency. elog messages do not present possible features during emerge --preted. So after reading elog message this requires user to run another emerge just to have all asciidoc features installed. elog-message approach complicates developement. Let's consider case where package foo depends on asciidoc with graph support. Without use flags foo-ver.ebuild have to contain something like: RDEPEND= app-text/asciidoc media-gfx/graphviz Now it is possible that graph provider for app-text/asciidoc changes (e.g. on graphviz-ng). In such case all this packages that require asciidoc with graph support will have to be updated (controrary to use-flag approach where asciidoc[graphviz] dependency is sufficient). Also sometimes more then one package is required to provide feature. net-im/psi it requires both net-im/psimedia and app-crypt/qca-ossl:2 for voice calls (jingle) support: PDEPEND= jingle? ( net-im/psimedia app-crypt/qca-ossl:2 ) net-im/psimedia builds fine without app-crypt/qca-ossl:2 but it is still required to have working jingle in psi. Such dependencies are not very evident for non-maintainer and may cause problems during upgrade if, say, another bar dependency will became required for jingle support, but user/developer will be not very attentive rereading yet another time ewarn messages. Also elog approach adds text into anyway overloaded elog output. Specification Starting with EAPI=X new prefix ~ is allowed in IUSE use flag definition. Use flags prefixed with ~ are not allowed to be used anywhere but only inside PDEPEND dependency specification. This USE flags are used during dependency resolution as normal. Package manager is allowed to skip re-installation of the package due to this USE flag change but still it should record such USE change into package database. Rationale Since use-flag approach has only one drawback it's good idea to fix it. Backwards Compatibility This should be inside some future EAPI thus is backward compatible. Already existing prefixes (+ and -) are allowed to be in any part of prefix, i.e. IUSE=~foo ~+bar +~baz should work. = Comments? May be instead of ~ introduce three additional prefixes (~ and another two for +~ and -~ cases)? -- Peter.
Re: [gentoo-dev] RFC: optinal run time dependencies
On Tue, 28 Jun 2011 14:38:19 +0400 Peter Volkov p...@gentoo.org wrote: Hi guys. We've had discussion on optional runtime dependencies in bug 361255, but I think it's worth to have broader discussion of this issue. Have you seen how Exherbo solved the same problem? exheres-0 has 'suggested' and 'recommended' dependencies, which are variations on post dependencies. Suggested dependencies are displayed (along with a description explaining what they do for the packages suggesting them) but not taken by default, and recommended dependencies are taken (but shown as just being recommended) unless the user says not to. To avoid annoyance, there are two special cases. First, if a suggested or recommended dependency is already installed, then it's treated like a regular post dependency for upgrades etc (so you don't have to take suggestions every single time). Second, there's a config file allowing users to permanently 'untake' or 'take things. So let's take an oversimplified 'git': DEPENDENCIES= suggestion: dev-perl/TermReadKey [[ description = [ Dependency for 'git add --interactive' ] ]] ( dev-perl/Authen-SASL dev-perl/Net-SMTP-SSL ) [[ *description = [ Dependency for 'git send-email' ] *group-name = [ git-send-email ] ]] Here, when a user first tries to install 'git', they get something like this (output abbreviated for clarity): n dev-scm/git:0::arbor 1.7.5.4 to ::installed bash-completion curl -doc -emacs -ipv6 python I did not take the following: (n) dev-perl/TermReadKey:0::arbor 2.30 to ::installed Change terminal modes, and perform non-blocking reads Reasons: dev-scm/git (sug): Dependency for 'git add --interactive' Take using: --take (n) dev-perl/Authen-SASL:0::arbor 2.15 to ::installed Perl SASL Authentication framework Reasons: dev-scm/git (sug): Dependency for 'git send-email' Take using: --take (git-send-email) (n) dev-perl/Net-SMTP-SSL:0::arbor 1.01 to ::installed SSL support for Net::SMTP Reasons: dev-scm/git (sug): Dependency for 'git send-email' Take using: --take (git-send-email) Here, the user can just go ahead and install 'git' if they like -- untaken dependencies are just informational, not an error. Or they can do some of the following: * They can '--take TermReadKey' etc. Or they can use the 'group name', like '--take git-send-email', since suggested dependencies often come in groups and it's handy that way. * Similarly, they can '--take-from git'. There's also '--ignore' and '--ignore-from'. They're not widely used in practice. * They can update the 'suggestions.conf' file to record their choice. But this isn't usually necessary, because of the if a suggestion is already installed, automatically take it behaviour. It's mostly used to say I've seen this suggestion, and don't want it, so don't show it to me again. Still, it's handy for suggestion groups if, say, git send-email's optional extra dependencies keep changing. Seems to work rather well in practice... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: optinal run time dependencies
On Tue, 28 Jun 2011 12:03:28 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Have you seen how Exherbo solved the same problem? exheres-0 has 'suggested' and 'recommended' dependencies, which are variations on post dependencies. Suggested dependencies are displayed (along with a description explaining what they do for the packages suggesting them) but not taken by default, and recommended dependencies are taken (but shown as just being recommended) unless the user says not to. Seems to me like just another configuration file for user to cope with. We can achieve the same results with the special USE Peter suggested and USE defaults, using the same configuration mechanism as usual. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: optinal run time dependencies
On Tue, 28 Jun 2011 14:38:19 +0400 Peter Volkov p...@gentoo.org wrote: Starting with EAPI=X new prefix ~ is allowed in IUSE use flag definition. Use flags prefixed with ~ are not allowed to be used anywhere but only inside PDEPEND dependency specification. This USE flags are used during dependency resolution as normal. Package manager is allowed to skip re-installation of the package due to this USE flag change but still it should record such USE change into package database. How about packages having optional rt dependencies on other packages' optional dependencies? Comments? May be instead of ~ introduce three additional prefixes (~ and another two for +~ and -~ cases)? I think a USE_EXPAND prefix could be used for that as well. We could then extend the backwards compatibility to cause complete package rebuilds with older PMs (EAPIs) and only dep-switches for newer ones. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: optinal run time dependencies
On 06/28/11 12:38, Peter Volkov wrote: Hi guys. We've had discussion on optional runtime dependencies in bug 361255, but I think it's worth to have broader discussion of this issue. [SNIP] Comments? I like the USEflag approach. It integrates well with the rest of the machinery. Speaking from experience with other distros that have optional dependency support - be really REALLY sure it's an absolutely optional feature that you handle like this. There's nothing worse than spending 15 minutes trying to figure out why stuff is broken, just to realize that the mandatory optional dependencies were not installed. (Yes, mandatory. But optional. Yey!) Since we have useflags anyway I don't really see a strong usecase for making some useflags different - we even have default-on and default-off methods, and if a user doesn't like something it's easy to change locally. But more metadata around the useflags might be very convenient. May be instead of ~ introduce three additional prefixes (~ and another two for +~ and -~ cases)? That looks a bit weird :) -- Patrick Lauer http://service.gentooexperimental.org Gentoo Council Member and Evangelist Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
Re: [gentoo-dev] RFC: optinal run time dependencies
On Tue, 28 Jun 2011 13:14:40 +0200 Michał Górny mgo...@gentoo.org wrote: On Tue, 28 Jun 2011 12:03:28 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Have you seen how Exherbo solved the same problem? exheres-0 has 'suggested' and 'recommended' dependencies, which are variations on post dependencies. Suggested dependencies are displayed (along with a description explaining what they do for the packages suggesting them) but not taken by default, and recommended dependencies are taken (but shown as just being recommended) unless the user says not to. Seems to me like just another configuration file for user to cope with. You obviously didn't pay attention, since the configuration file is the least relevant bit of the whole thing. If you really think that too many configuration files is a bigger problem than making reinstalls suddenly not reinstall stuff, though, then tracking not-taken suggestions is trivial. Having real world experience with all of this, I can assure you that configuration files are not what cause user difficulties. We can achieve the same results with the special USE Peter suggested and USE defaults, using the same configuration mechanism as usual. You *could*, yes. But then that's yet another perversion on what USE flags are, and it means that suddenly reinstalling isn't reinstalling any more (what if a user wants to reinstall something, but that it doesn't get reinstalled because the package mangler thinks that you're just altering flags?). Do you really want a user to have to 'reinstall' something twice to reinstall it? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Thoughts about broken package handling
В Втр, 28/06/2011 в 07:17 +0100, Ciaran McCreesh пишет: There was going to be a really simple, elegant, ebuild-controllable and provably working fix for that in EAPI 4 in the form of := deps, but they got dropped because Portage couldn't implement it. Which is strange, because it should have been a ten minute job... There is a good opportunity to resubmit this for EAPI=5 ;) -- Peter.
Re: [gentoo-dev] RFC: optinal run time dependencies
On Tue, 28 Jun 2011 12:19:43 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 28 Jun 2011 13:14:40 +0200 Michał Górny mgo...@gentoo.org wrote: On Tue, 28 Jun 2011 12:03:28 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Have you seen how Exherbo solved the same problem? exheres-0 has 'suggested' and 'recommended' dependencies, which are variations on post dependencies. Suggested dependencies are displayed (along with a description explaining what they do for the packages suggesting them) but not taken by default, and recommended dependencies are taken (but shown as just being recommended) unless the user says not to. Seems to me like just another configuration file for user to cope with. You obviously didn't pay attention, since the configuration file is the least relevant bit of the whole thing. If you really think that too many configuration files is a bigger problem than making reinstalls suddenly not reinstall stuff, though, then tracking not-taken suggestions is trivial. Having real world experience with all of this, I can assure you that configuration files are not what cause user difficulties. Ah, I missed the point of not having to rebuild packages. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] The Python problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28-06-2011 07:19, Dirkjan Ochtman wrote: On Tue, Jun 28, 2011 at 08:54, Joshua Saddler nightmo...@gentoo.org wrote: This would be nice, but unfortunately the python maintainer forced 3.x on everyone, despite the fact that nothing uses it and no one really wanted it made the default. So now it's shipped with all the stage tarballs, in addition to 2.7. You've got it whether you want it or not. This is one of the things that needs to be rescinded, along with the python eclass changes. Get everyone down to just one version of python installed. It's just slotting like everything else. (There's an open bug for the stages.) Yes, but with slotting you allow different packages to pull in different slots of python. Furthermore, when you slot a package and mark more than one slot stable, you're saying that all the stable slots work and don't break the tree. About the stages bug (330361), as was discussed to exhaustion on the bug, mls, IRC and many other locations, python3 isn't added to the stages by the will or work of releng. Cheers, Dirkjan - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOCb93AAoJEC8ZTXQF1qEPurcQAKj3i7pL22kd2EpmG2+tDdcg us3xE2dQofp6hVkiSkz6LVQuyCEH9QV/jujSkwYJLVPDsGGyXzBIkUGA9iLc2iDQ nJx2r2QqZe11CxOuyd15AomVsLDazDGq8mxkxIBzJl9l9xS5HINqL+D79HxiOsdE oraOL/cr4tbjDLWgraLZMXM/QPUkhqXkQurgn1uF4U4TAkvjZessJwe2Csi6raUW xhJ42HAF+Q+VpFuTlBJfJevNsXnyHR4y6qM4xFF5X6sIyPodz3CORfHBMAXrU/pX MCsMSPRJQRIAc26tEf+V4WJuUsp+yaydejPnEiyZSnDBDmgeS7zgEhQRLAPf+//Y sMEMqchTAkwS4gxyAyl6AoR3+DFlGZdcTmn2S+AbtQNH318Lt3yamGbwRUMpjUHX p8YXxsjL6iigyIUaJt594W1Bc2gS6ktkQGUqERLvM0dYUSoQcZJCeWq7y+qO/3vF uukqOnljgSEvucijeHUM3623ImgpoCw3tzw7UGz74PunqqqL37op7FxX55exyYWw TjzDqFEPlnaNQNvD3E3dZdU+/KnUlmn9Jtbxv/o04unVfEFspGP9DeuZYUOolWAG 86LFsL9PeSGLhqgxWbFjMR4lmznilnlaaB+4MmEtMV3K3FGdsI/68dhGRNe+oEC7 8JTT1DDZpunk0coni/f3 =aUwd -END PGP SIGNATURE-
Re: [gentoo-dev] The Python problem
On Tue, Jun 28, 2011 at 13:48, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: Yes, but with slotting you allow different packages to pull in different slots of python. Furthermore, when you slot a package and mark more than one slot stable, you're saying that all the stable slots work and don't break the tree. And that's true for Python AFAICT. About the stages bug (330361), as was discussed to exhaustion on the bug, mls, IRC and many other locations, python3 isn't added to the stages by the will or work of releng. Right; I've also stated my opinion on this exhaustively in that bug. Cheers, Dirkjan
Re: [gentoo-dev] Are tags just sets?
В Пнд, 27/06/2011 в 20:26 -0700, Brian Harring пишет: Second, make a bunch of sets named kde-tag, editors-tag, xml-tag, monkeys-tag etc. I'd like avoid editing multiple files. Much better will be keep tags with package. Counter proposal; use what you're proposing as a cache. metadata.xml is the proper place for this ++ Roughly, and this is definitely a rough sketch: tags atom val=dev-util/diffballtag1 tag2 tag2 tag3/atom atom val==dev-util/diffball-1.0awesomeness/atom /tags Since use dependencies eapi should be provided somewhere. Also I like metadata.xml proposal since it'll be easy to use per-category metadata.xml for all ebuilds to inherit. -- Peter.
Re: [gentoo-dev] SHA256 and indention in metadata.xml
В Вск, 26/06/2011 в 17:20 +0200, Maciej Mrozowski пишет: I never understood the reason after keeping deps not sorted alphabetically where order doesn't matter - it's like someone purposely made ebuild harder to read - it's counter productive. Like with perl modules with well written configure.ac I like them to be sorted in the order there. This way makes easier for me to see if there is anything redundant in deps or not. -- Peter.
Re: [gentoo-dev] SHA256 and indention in metadata.xml
В Сбт, 25/06/2011 в 13:24 -0400, Mike Frysinger пишет: On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote: On Sat, Jun 25, 2011 at 6:16 PM, justin wrote: Another question, do we have a rule, how the metadata.xml has to be indented? Tabs or n spaces? There's no rule, but we should follow the same rule as ebuilds — indentation should be with a tab that's displayed as 4 spaces in editors (no expansion of tabs to spaces). meh ... let devs do whatever they want Why? This looks like perfect case to use standard indentation. Personally I'd like indentation to be fixed (and I don't really care how). -- Peter.
Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
Thank you Fabian, Michał. Added note on Makefile and mentioned other
tools as well. Updated patch is in attachment.
--
Peter.
From 9d24f4bab09be481e70ab04c85f20a246162dc0a Mon Sep 17 00:00:00 2001
From: Peter Volkov p...@gentoo.org
Date: Tue, 28 Jun 2011 10:05:17 +0400
Subject: [PATCH] Use | as a separator for sed'ing CFLAGS
/, : is a bad idea per thread on gentoo-dev:
http://archives.gentoo.org/gentoo-dev/msg_654cd9daf2548a524c8a09a82b80916f.xml
---
.../functions/src_compile/building/text.xml| 31 +++
1 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/ebuild-writing/functions/src_compile/building/text.xml b/ebuild-writing/functions/src_compile/building/text.xml
index 700f0f1..1bc3ec2 100644
--- a/ebuild-writing/functions/src_compile/building/text.xml
+++ b/ebuild-writing/functions/src_compile/building/text.xml
@@ -43,10 +43,24 @@ It is enot/e correct to use the c${CC}/c variable for this purpose.
/note
p
-Sometimes a package will not use the user's c${CFLAGS}/c or c${LDFLAGS}/c.
-This must be worked around, as sometimes these variables are used for specifying
-critical ABI options. In these cases, the build scripts should be modified (for
-example, with csed/c) to use c${CFLAGS}/c or c${LDFLAGS}/c correctly.
+Sometimes a package will not use the user's c${CFLAGS}/c or
+c${LDFLAGS}/c. This must be worked around, as sometimes these variables are
+used for specifying critical ABI options. In some cases it's enough to pass
+correct parameters for the cemake/c (check Makefile to see if this is
+possible):
+/p
+
+codesample lang=ebuild
+EAPI=4
+
+src_compile() {
+ emake CC=$(tc-getCC) CFLAGS=${CFLAGS}
+}
+/codesample
+
+p
+In other cases, the build scripts should be modified (for example, with
+csed/c) to use c${CFLAGS}/c or c${LDFLAGS}/c correctly.
/p
codesample lang=ebuild
@@ -58,15 +72,18 @@ src_compile() {
# We have a weird build.sh to work with which ignores our
# compiler preferences. yay!
-sed -i -e s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}: build.sh \
+sed -i -e s|cc -O2|$(tc-getCC) ${CFLAGS} ${LDFLAGS}| build.sh \
|| die sed fix failed. Uh-oh...
./build.sh || die Build failed!
}
/codesample
note
-When using csed/c with cCFLAGS/c or cLDFLAGS/c, it is not safe to use
-a comma or a slash as a delimiter. The recommended character is a colon.
+When using csed/c with cCFLAGS/c or cLDFLAGS/c, it is not safe to
+use a comma, a colon or a slash as a delimiter. cgcc/c, cld/c,
+car/c, etc... options may contain this characters so csed/c will fail
+after bash expansion. The recommended character is a vertical bar: '|' (the
+pipe).
/note
p
--
1.7.3.4
Re: [gentoo-dev] ldconfig symlink updates -- do we need that?
On 28/06/11 10:53, Michał Górny wrote: On Tue, 28 Jun 2011 10:48:48 +0200 Michał Górny mgo...@gentoo.org wrote: I'm a noob in Python, but I disagree with this patch. for two reasons: First, the -X option is already available, and controlled by makelinks, so why not change the default value of makelinks to False? Second, after trying to understand the code, if your proposed patch is applied, the makelinks variable become useless. So why not remove it completly from the source? Is this variable still needed? There is some bunch of code starting at line 222 in the current HEAD, which sets makelinks to False upon some conditions, does this need to be refactored / removed somehow too? -- Cyprien Nicolas (fulax) Lisp project contributor
Re: [gentoo-dev] Are tags just sets?
On Tue, Jun 28, 2011 at 07:53, Peter Volkov p...@gentoo.org wrote: В Пнд, 27/06/2011 в 20:26 -0700, Brian Harring пишет: Second, make a bunch of sets named kde-tag, editors-tag, xml-tag, monkeys-tag etc. I'd like avoid editing multiple files. Much better will be keep tags with package. snip / Also I like metadata.xml proposal since it'll be easy to use per-category metadata.xml for all ebuilds to inherit. You weren't planning on doing this all _manually_, were you? ;) With proper tool support (or even just a couple quick scripts), the single/multiple file argument becomes pretty much moot. Another thing I think should be reiterated is that leveraging sets in this matter gets us implication and aliasing for free (as long as sets can be included inside of other sets). I'm not sure it would be so easy to accomplish otherwise. Regards, Wyatt
Re: [gentoo-dev] SHA256 and indention in metadata.xml
On Tuesday, June 28, 2011 08:02:03 Peter Volkov wrote: В Сбт, 25/06/2011 в 13:24 -0400, Mike Frysinger пишет: On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote: On Sat, Jun 25, 2011 at 6:16 PM, justin wrote: Another question, do we have a rule, how the metadata.xml has to be indented? Tabs or n spaces? There's no rule, but we should follow the same rule as ebuilds — indentation should be with a tab that's displayed as 4 spaces in editors (no expansion of tabs to spaces). meh ... let devs do whatever they want Why? This looks like perfect case to use standard indentation. Personally I'd like indentation to be fixed (and I don't really care how). these files are so small/minor, and now we tread into xml territory which has much less standardized indenting and line wrapping rules. it isnt simply a matter of how much space do i put before an open tag. i really dont see it being a problem that needs solving. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
On Tuesday, June 28, 2011 02:54:03 Michał Górny wrote:
On Tue, 28 Jun 2011 10:16:06 +0400 Peter Volkov wrote:
But still our documentation explicitly suggests ':' for CFLAGS cases
and example allows bash substitution.
http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/building
/index.html see example in Fixing Compiler Usage section and text
below:
sed -i -e s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}: build.sh
Are there any objections to suggest '|' for CFLAGS, LDFLAGS (see
attachment)?
I think that also a good idea may be to provide an Makefile example,
showing that often sed is unnecessary, and it's enough to do things
like:
emake CC=$(tc-getCC) CFLAGS=${CFLAGS}...
this is easily dangerous when it comes to packages (and many do) that append
in the Makefile. specifying on the command line blocks those while passing
via env works fine. i'm not sure it's appropriate to provide as an example.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
On Tuesday, June 28, 2011 08:25:50 Peter Volkov wrote:
+Sometimes a package will not use the user's c${CFLAGS}/c or
+c${LDFLAGS}/c.
there are more flag vars than this. you should use language like:
Sometimes a package will not use the user's build settings (such as CFLAGS or
LDFLAGS).
-sed -i -e s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}: build.sh \
+sed -i -e s|cc -O2|$(tc-getCC) ${CFLAGS} ${LDFLAGS}| build.sh \
probably better to suggest delaying of the expansion in the first place.
sed -i -e s|cc -O2|$(tc-getCC) \${CFLAGS} \${LDFLAGS}| build.sh \
also, your example ignores CPPFLAGS
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] demanual update
On 6/28/11 6:23 PM, Mike Frysinger wrote:
On Tuesday, June 28, 2011 02:54:03 Michał Górny wrote:
On Tue, 28 Jun 2011 10:16:06 +0400 Peter Volkov wrote:
But still our documentation explicitly suggests ':' for CFLAGS cases
and example allows bash substitution.
http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/building
/index.html see example in Fixing Compiler Usage section and text
below:
sed -i -e s:cc -O2:$(tc-getCC) ${CFLAGS} ${LDFLAGS}: build.sh
Are there any objections to suggest '|' for CFLAGS, LDFLAGS (see
attachment)?
I think that also a good idea may be to provide an Makefile example,
showing that often sed is unnecessary, and it's enough to do things
like:
emake CC=$(tc-getCC) CFLAGS=${CFLAGS}...
this is easily dangerous when it comes to packages (and many do) that append
in the Makefile. specifying on the command line blocks those while passing
via env works fine. i'm not sure it's appropriate to provide as an example.
-mike
There are cases and cases. You are right with what you said. But cases
where the makefile appends stuff are not the typical cases where a sed
is applied. Normally sed is used if upstream hardcodes FLAGS we don't
want. And there the passing with emake is the appropriate safer way for
a fix.
justin
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
В Втр, 28/06/2011 в 12:23 -0400, Mike Frysinger пишет:
On Tuesday, June 28, 2011 02:54:03 Michał Górny wrote:
emake CC=$(tc-getCC) CFLAGS=${CFLAGS}...
this is easily dangerous when it comes to packages (and many do) that append
in the Makefile. specifying on the command line blocks those while passing
via env works fine. i'm not sure it's appropriate to provide as an example.
Hm, I'm not sure I understand what you are talking about here. Could you
provide example?
--
Peter.
Re: [gentoo-dev] demanual update
On Tuesday, June 28, 2011 12:37:41 justin wrote:
On 6/28/11 6:23 PM, Mike Frysinger wrote:
On Tuesday, June 28, 2011 02:54:03 Michał Górny wrote:
I think that also a good idea may be to provide an Makefile example,
showing that often sed is unnecessary, and it's enough to do things
like:
emake CC=$(tc-getCC) CFLAGS=${CFLAGS}...
this is easily dangerous when it comes to packages (and many do) that
append in the Makefile. specifying on the command line blocks those
while passing via env works fine. i'm not sure it's appropriate to
provide as an example. -mike
There are cases and cases. You are right with what you said. But cases
where the makefile appends stuff are not the typical cases where a sed
is applied. Normally sed is used if upstream hardcodes FLAGS we don't
want.
and those packages should get patched and the patch sent upstream which means
the sed+cmdline is still unnecessary.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
On Tue, Jun 28, 2011 at 10:24:26PM +0400, Peter Volkov wrote:
?? ??, 28/06/2011 ?? 12:23 -0400, Mike Frysinger ??:
On Tuesday, June 28, 2011 02:54:03 Micha?? G??rny wrote:
emake CC=$(tc-getCC) CFLAGS=${CFLAGS}...
this is easily dangerous when it comes to packages (and many do) that
append
in the Makefile. specifying on the command line blocks those while passing
via env works fine. i'm not sure it's appropriate to provide as an example.
Hm, I'm not sure I understand what you are talking about here. Could you
provide example?
I think he's referring to somethine like:
Makefile:
CFLAGS += `pkg-config --cflags libxml-2.0`
which would work fine for:
emake
but which would override the pkg-config flags if you do:
emake CFLAGS=${CFLAGS}
--
binki
pgpwm9rxY2Hpm.pgp
Description: PGP signature
Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
On Tue, 28 Jun 2011 22:24:26 +0400
Peter Volkov p...@gentoo.org wrote:
В Втр, 28/06/2011 в 12:23 -0400, Mike Frysinger пишет:
On Tuesday, June 28, 2011 02:54:03 Michał Górny wrote:
emake CC=$(tc-getCC) CFLAGS=${CFLAGS}...
this is easily dangerous when it comes to packages (and many do)
that append in the Makefile. specifying on the command line blocks
those while passing via env works fine. i'm not sure it's
appropriate to provide as an example.
Hm, I'm not sure I understand what you are talking about here. Could
you provide example?
if the makefile contains something like CFLAGS+=-DMYFEATURE=1 then
'emake CFLAGS=blah' overrides it but 'CFLAGS=blah emake' doesnt.
A.
Re: [gentoo-dev] Are tags just sets?
On Tuesday 28 of June 2011 05:26:29 Brian Harring wrote: On Sun, Jun 26, 2011 at 08:02:57AM +0100, Ciaran McCreesh wrote: Here's a completely different way of doing tags: First, standardise sets. We probably want to go with a format along the lines of: eapi = 4 description = Monkeys dev-monkey/howler dev-monkey/spider =dev-monkey/spanky-2.0 dev-monkey/squirrel where eapi has to be on the first line. Second, make a bunch of sets named kde-tag, editors-tag, xml-tag, monkeys-tag etc. This is a bit inverted- tagging is fundamentally pkg specific. If we did as you proposed and I wanted to find out all tags/descriptions for a pkg, the PM would have to scan every tags file there. Additionally, as others have indicated, it sucks have this data tucked away in another chunk of the tree, away from where the package data actually is (in cat/pkg/*). Advantages: dead easy to implement, backwards compatible, we need sets anyway. Disadvantages: doesn't use some horribly convoluted system of XML, wikis and web 2.0. Counter proposal; use what you're proposing as a cache. metadata.xml is the proper place for this- we store use.local data there for example, and cache the results of it in profiles/use.local.desc. Via this vcs concerns are addressed, data locality is preserved, and multiple modes of lookup are sanely supported. Roughly, and this is definitely a rough sketch: tags atom val=dev-util/diffballtag1 tag2 tag2 tag3/atom atom val==dev-util/diffball-1.0awesomeness/atom /tags From there, jammed into profiles, a master description list in 'tag: description' style format. Identifying the eapi is easy enough- just inspect the atom's that wind up in the tags list. Easy enough. Either way... thing everyone admits the current tree format has it's flaws; strikes me it's better to fit to the standards/conventions of the repo format as it is now. proceed w/ xml bashing ~harring Of course, nobody said metadata.xml would be the place that's to be immediately accessed by search tools. But as a data definition is concerned, metadata.xml is the right place for tags, not some obscure 'package.mask'- style flat file. Whether this information is to be processed for easier usage - by generating flat file with cat/pkg tag1 tag2 ... in each line for instance - is different story and nice to have probably. @Ciaran profiles/package.mask is quite convenient being flat file (although package.mask.d seems nicer, different story) as masking/unmasking groups of packages (KDE releases come to my mind) is a common use case. Sure, it would benefit from auto-updating (pkgmove mostly as package.mask editing is otherwise closely tied to package removals anyway). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
On Tue, 28 Jun 2011 15:04:00 -0400
Nathan Phillip Brink bi...@gentoo.org wrote:
On Tue, Jun 28, 2011 at 10:24:26PM +0400, Peter Volkov wrote:
?? ??, 28/06/2011 ?? 12:23 -0400, Mike Frysinger ??:
On Tuesday, June 28, 2011 02:54:03 Micha?? G??rny wrote:
emake CC=$(tc-getCC) CFLAGS=${CFLAGS}...
this is easily dangerous when it comes to packages (and many do)
that append in the Makefile. specifying on the command line
blocks those while passing via env works fine. i'm not sure it's
appropriate to provide as an example.
Hm, I'm not sure I understand what you are talking about here.
Could you provide example?
I think he's referring to somethine like:
Makefile:
CFLAGS += `pkg-config --cflags libxml-2.0`
which would work fine for:
emake
but which would override the pkg-config flags if you do:
emake CFLAGS=${CFLAGS}
But is overriding really useful in this particular case? It seems
rather irrelevant here.
AFAIR you can pass 'emake CFLAGS+=sth' too but not sure about that.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
All, the reason for this email is http://bugs.gentoo.org/show_bug.cgi?id=373219 and the bugs that currently depend on it. I'm sure there will be more of those. The background is that /etc/init.d/functions.sh is a link to /lib/rc/functions.sh, which is part of openrc. Other init systems, like systemd, are coming along which completely replace sysvinit and do not use openrc's init scripts at all. However, since things other than init scripts are using /etc/init.d/functions.sh, all gentoo users are forced to have openrc on their systems whether they use its init scripts or not. As you can see in the bug, I am working on creating a minimalist version of openrc that can be installed to allow users to have access to the functions that are in functions.sh regardless of whether or not they are using openrc's init system. I'm not convinced that this is the best approach, so any input would be greatly appreciated. William pgp8kHkUnVT18.pgp Description: PGP signature
Re: [gentoo-dev] The Python problem
On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman d...@gentoo.org wrote: Hi guys, [...] So I know a bunch of people have already looked at it, and I'd like to know: what do you find better about the Ruby approach compared to the Python approach? Is it just the size of python.eclass, or are there a number of other issues? Cheers, Dirkjan Let´s start by agreeing with the complexity of the Python eclass. And a heavy change right now, is going to be painful to say the least because a great deal of packages have been adapted to work the way the eclass works right now. I agree with Grobian in what he said about the coding style of the python.eclass, and would love to see that fixed. I also agree with the redundancy of some variables and I think just using PYTHON_DEPEND should be sufficient to let the PM know what should be done with a specific package. With python-updater, well, some time ago Ali Polatel implemented some approaches to get rid of python-updater, by exporting some variable in ebuilds that needed to be rebuilt when new python versions were installed. I dont recall what happened with that, but we could think of some ways to finally get rid of python-updater. WRT python3, I too believe it is important to have it stable. Thing is, for better or worse, upstream have it stable, and py2 and py3 are going to co-exist for a long time. Thing is, we should really figure out a way to have it stop messing things up. I believe with a proper dependency handling in the eclass, we could get this to work. As I said it already, we could start doing things simpler in the current python.eclass and maybe that would attract some devs to help out with it, as they find it more comfortable to work with. Best regards, -- Jesus Rivero (Neurogeek) Gentoo Developer
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
Hi, On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote: The background is that /etc/init.d/functions.sh is a link to /lib/rc/functions.sh, which is part of openrc. Other init systems, like systemd, are coming along which completely replace sysvinit and do not use openrc's init scripts at all. However, since things other than init scripts are using /etc/init.d/functions.sh, all gentoo users are forced to have openrc on their systems whether they use its init scripts or not. As you can see in the bug, I am working on creating a minimalist version of openrc that can be installed to allow users to have access to the functions that are in functions.sh regardless of whether or not they are using openrc's init system. I'm not convinced that this is the best approach, so any input would be greatly appreciated. As long as we have Gentoo-style init scripts in the tree, we will need these functions to be available. So yes, they should probably be in a separate package from openrc itself to ease the transition to the bright systemd future. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
Hi, On Tue, Jun 28, 2011 at 09:07:12PM -0400, Olivier Crête wrote: Hi, On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote: The background is that /etc/init.d/functions.sh is a link to /lib/rc/functions.sh, which is part of openrc. Other init systems, like systemd, are coming along which completely replace sysvinit and do not use openrc's init scripts at all. However, since things other than init scripts are using /etc/init.d/functions.sh, all gentoo users are forced to have openrc on their systems whether they use its init scripts or not. As you can see in the bug, I am working on creating a minimalist version of openrc that can be installed to allow users to have access to the functions that are in functions.sh regardless of whether or not they are using openrc's init system. I'm not convinced that this is the best approach, so any input would be greatly appreciated. As long as we have Gentoo-style init scripts in the tree, we will need these functions to be available. So yes, they should probably be in a separate package from openrc itself to ease the transition to the bright systemd future. I'm not advocating killing openrc; I think that the sysvinit/openrc system we have is going to be our default init system for some time It isn't init scripts that I'm worried about. The problem is that scripts other than init scripts are using the code in /etc/init.d/functions.sh, so some how that code, or something similar to it needs to be available on systems so that someone, like yourself, who is not using openrc, can run emerge --unmerge sysvinit openrc and have a working system. Right now, things like revdep-rebuild and eix will break if you remove openrc. For the short term I can see it as a subset of openrc, but ultimately I think if you aren't using openrc's init system it should not be required on your system. Any other thoughts? William pgp2KCLgV0LMi.pgp Description: PGP signature
Re: [gentoo-dev] RFC: optinal run time dependencies
On 14:38 Tue 28 Jun , Peter Volkov wrote: 1. add a use flag to control runtime dependency 2. add elog message into pkg_postinst to notify users that some features depend on installing package A, B, etc. I've got a suggestion that builds a little bit on what both you and Ciaran have said. The UI could probably be clearer if we added a new dependency type like SDEPEND (suggested deps) with USE flags for different features. That would enable portage to show things in a special way if it knew about SDEPEND. Yet it wouldn't do anything weird that broke backwards compatibility or produced strange output from noncompliant PMs (like USE flag modifications). Then PMs would be free to implement their own logic for how to handle it. For Portage, I'd like to see a few cases: 1) If a package is installed, assume it's desired, as Ciaran proposed. 2) Add a way to determine whether to install all/none/groups of them, w/ configuration in /etc/portage/package.suggestions/. Probably CPV followed by the setting (all, none, specific groups, or specific CPVs). Add an option similar to --autounmask that would let Portage write to this file. 3) Something like the --take argument and friends that Ciaran mentioned seems reasonable (perhaps --accept-suggestion, w/ a short option to save typing). Problems? Other thoughts? -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpEUroOHMuW9.pgp Description: PGP signature
Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
On Tuesday, June 28, 2011 15:58:46 Michał Górny wrote:
On Tue, 28 Jun 2011 15:04:00 -0400 Nathan Phillip Brink wrote:
On Tue, Jun 28, 2011 at 10:24:26PM +0400, Peter Volkov wrote:
?? ??, 28/06/2011 ?? 12:23 -0400, Mike Frysinger ??:
On Tuesday, June 28, 2011 02:54:03 Micha?? G??rny wrote:
emake CC=$(tc-getCC) CFLAGS=${CFLAGS}...
this is easily dangerous when it comes to packages (and many do)
that append in the Makefile. specifying on the command line
blocks those while passing via env works fine. i'm not sure it's
appropriate to provide as an example.
Hm, I'm not sure I understand what you are talking about here.
Could you provide example?
I think he's referring to somethine like:
Makefile:
CFLAGS += `pkg-config --cflags libxml-2.0`
which would work fine for:
emake
but which would override the pkg-config flags if you do:
emake CFLAGS=${CFLAGS}
But is overriding really useful in this particular case? It seems
rather irrelevant here.
if the Makefile starts off with
CFLAGS = hardcode
and then in subdirs it appends, then yes
or people split up the initial hardcode and latter pkg-config appends as
Nathan showed, then yes
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Tue, 28 Jun 2011 17:10:42 -0500 William Hubbs willi...@gentoo.org wrote: the reason for this email is http://bugs.gentoo.org/show_bug.cgi?id=373219 and the bugs that currently depend on it. I'm sure there will be more of those. The background is that /etc/init.d/functions.sh is a link to /lib/rc/functions.sh, which is part of openrc. Other init systems, like systemd, are coming along which completely replace sysvinit and do not use openrc's init scripts at all. However, since things other than init scripts are using /etc/init.d/functions.sh, all gentoo users are forced to have openrc on their systems whether they use its init scripts or not. As you can see in the bug, I am working on creating a minimalist version of openrc that can be installed to allow users to have access to the functions that are in functions.sh regardless of whether or not they are using openrc's init system. I'm not convinced that this is the best approach, so any input would be greatly appreciated. Honestly, I think a better solution would be to provide a convenience function library, independent of OpenRC. Sourcing random internal scripts of a random package is just broken by concept. Say, if OpenRC decided to switch into some kind of internal output flow, einfo and friends would stop working for all those external scripts. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] The Python problem
On Tue, 28 Jun 2011 20:03:34 -0430 Jesus Rivero (Neurogeek) neurog...@gentoo.org wrote: On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman d...@gentoo.org wrote: Hi guys, [...] So I know a bunch of people have already looked at it, and I'd like to know: what do you find better about the Ruby approach compared to the Python approach? Is it just the size of python.eclass, or are there a number of other issues? Let´s start by agreeing with the complexity of the Python eclass. And a heavy change right now, is going to be painful to say the least because a great deal of packages have been adapted to work the way the eclass works right now. [...] As I said it already, we could start doing things simpler in the current python.eclass and maybe that would attract some devs to help out with it, as they find it more comfortable to work with. I think it would be better to simply start from scratch with a clean python-2.eclass. Instead of adding new features and another lot of conditionals for EAPI=4, just make that code a part of new eclass. And remember, the more complex code is, the more painful it becomes for things like metadata generation. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote: Honestly, I think a better solution would be to provide a convenience function library, independent of OpenRC. Sourcing random internal scripts of a random package is just broken by concept. except it hasnt been random and has clearly been defined by having existed since the beginning of Gentoo Say, if OpenRC decided to switch into some kind of internal output flow, einfo and friends would stop working for all those external scripts. this idea is pure ridiculousness -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote: Honestly, I think a better solution would be to provide a convenience function library, independent of OpenRC. Sourcing random internal scripts of a random package is just broken by concept. except it hasnt been random and has clearly been defined by having existed since the beginning of Gentoo I have no idea what this is supposed to mean. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
