[gentoo-portage-dev] LC_ALL and friends in make.conf
This is an old issue, but I want to suggest a re-visit :) As we all know, setting LC_ALL and friends can cause all sorts of trouble in package builds. However, many users really appreciate being able to set it so that errors from the compiler etc are in their own language. It occurs to me that during emerge, only LC_MESSAGES is actually useful for the user, to help interpret build errors. LC_COLLATE and the others don't give the user any benefit in the emerge process. So how about if LANG or LC_* are set, portage would set LC_MESSAGES and clear the rest? Is there any real advantage to the user having LC_* set apart from LC_MESSAGES? -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [RFC] Depending on active version
On Wed, 31 Jan 2007 12:27:10 -0500
Alec Warner [EMAIL PROTECTED] wrote:
Hmm; one could get the same benefit by introducing a new interface
(e.g. pkg_env_check()) which is defined to return true if the
environment is ok, false otherwise (with some text to stdout,
perhaps). The package manager would then run this function, after
building the depgraph and finding the candidate packages to merge,
for each candidate package - if any package fails is env_check,
none of the packages get emerged. Note this is then completely
independent of depgraph creation.
In the 'tr1' example, I'd imagine something like this:
use.local.desc: boost: Use boost library for tr1 rather than gcc's.
ebuild:
...
inherit ... toolchain-funcs versionator ...
...
DEPEND=... boost? ( dev-libs/boost ) ...
...
pkg_env_check() {
use boost return 0
version_is_at_least 4.1 $(gcc-version) return 0
echo Either USE boost, or switch to gcc later than 4.1
}
(with a default definition, pkg_env_check() { return 0; } )
In an ideal system you'd want this stuff in the metadata cache so that
the resolver can deal with it up front.
You're talking about the metadata on the host, rather than the stuff on
the rsync servers? I'm not sure you could cache the results even on
the host - you would need to know what could affect the results so as
to know when the cached information is out of date and has to be
recalculated. That would either have to checked on every emerge, or
made a separate switch (i.e. rely on the user to tell emerge when the
environment has changed).
All resolution is a brute
force metadata search; and assuming we had all the necessary data up
front, we can optimize the search there (see pkgcore and restriction
subsystem) versus IMHO doing a 'dumb' search and then running through
a list of criteria for inclusion.
This is the same reason why built_with_use in pkg_setup is really just
use_deps; these metadata should be included during resolution, not
after.
My concern about dynamic dependencies runs to use deps, as well :)
One could consider use-deps to be a special case of Marius' active
checks. how pkg P was built isn't so different from slot S of P is
active in terms of dep-graph creation; both are asking about the
state of host target systems, rather than the tree.
In the case of USE deps, things are saner because the data doesn't
change without the package manager knowing about it. Effectively the
depgraph becomes static w.r.t. the tree + installation record (rather
than just static w.r.t. the tree). With active checks implemented in
the depgraph, however, that is no longer the case - the depgraph can
change independently of the tree and the installation record.
With that said, I'm not sure how easy it would be to rewrite that
code; and this is simpler in that it's just a few bash functions as
opposed to more resolver foo.
There's a lot to be said for keeping things simple, of course :) It's
easy enough to mess up things like dep-graphs in any case - introducing
these sorts of dynamic dependencies can render it substantially more
complex.
Another way to look at it, is to consider how often this sort of thing
comes up. My understanding is that it is relatively rare; across the
10,000+ packages in the tree only a handful use 'built_with_use' fex.
That makes a strong case for having a simple solution in the near term,
and re-visit if it becomes commonplace.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] tiny manpage fix
On Thu, 25 May 2006 21:57:30 -0400 Alec Warner [EMAIL PROTECTED] wrote: Attached is a tiny diff for make.conf, can someone with l337 skills in manpages look it over before it gets commited. Easiest way to check how a man page looks is to do: nroff -man raw man page | less -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-portage-dev] tiny manpage fix
On Fri, 26 May 2006 02:28:44 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Friday 26 May 2006 02:27, Kevin F. Quinn wrote: On Thu, 25 May 2006 21:57:30 -0400 Alec Warner [EMAIL PROTECTED] wrote: Attached is a tiny diff for make.conf, can someone with l337 skills in manpages look it over before it gets commited. Easiest way to check how a man page looks is to do: nroff -man raw man page | less huh ? how is that easier than `man ./make.conf.5` :} that's what I get for growing up on SunOS (where that doesn't work) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Re: User created package lists
On Tue, 21 Mar 2006 10:50:00 -0600
MIkey [EMAIL PROTECTED] wrote:
Add the capability for emerge to take a category as an argument,
# (cd ${PORTDIR_OVERLAY} emerge -pv category/*)
Then the user can create overlays with their own category names and
symlink in the package directories they want from the real portage
tree.
This won't work, I think, since depend atoms include the category name
so if one package in the new category depends on another one, it will
use the standard category rather than the symlinked one in the new
category.
However with regards the original question about adding '--list
file' to emerge, you can of course to package lists yourself anyway
as portage exists today. Just create a file with a list of atoms in
it, and do for example:
# cat file | xargs emerge -puv
Doesn't get much easier than that - perhaps I'm missing something :)
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
On Wed, 8 Mar 2006 00:17:52 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:
how does the attached patch look ? it allows for regexes in the
ignore list which is why i used gawk ;)
Could we add something so that we can disable these ignore lists in the
hardened profile? At least something like:
if [[ -n ${QA_STRICT_TEXTRELS} ]]; then
f=$(scanelf -qyRF '%t %p' ${D})
else
filter version
fi
...
where we can add QA_STRICT_TEXTRELS to make.defaults.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
On Sun, 5 Mar 2006 20:46:25 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Sunday 05 March 2006 19:48, Kevin F. Quinn (Gentoo) wrote: This could be done via the profiles, perhaps - package.qa, something like package.mask/use/keywords: i hate such things ... imo this information should stay in the ebuild and nowhere else ... I was thinking that the data would be owned by the QA team rather than the package maintainers. I appreciate your pov, however. There may be benefit in being able to set it differently for each profile; for example a hardened (PaX NOELFRELOCS) profile might always have QA_TEXTRELS set empty (i.e. anything with TEXTRELs would fail to install, as it'd fail to run anyway). However package maintainers in general aren't going to like yet more special-casing for the non-mainstream profiles. Anyway, that aside - if you're going for a QA_feature_arch naming, you could use QA_feature where there's no arch difference, supplying others where necessary such that if QA_feature_arch exists it takes precedence over QA_feature. Otherwise you'll end up adding a whole set of variables to all affected ebuilds. Admittedly there aren't that many of them so it may not be worth the hassle. Heh - here's another idea for you to hate: QA_OVERRIDE=EXECSTACK=... x86? ( TEXTRELS=... ) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
On Sat, 04 Mar 2006 19:56:41 -0500 Ned Ludd [EMAIL PROTECTED] wrote: On Fri, 2006-03-03 at 23:32 -0500, Mike Frysinger wrote: so we've found some cases where a package installs objects that either need to be ignored by some of the scanelf checks ... ... what this e-mail is about is naming convention ... i'm thinking that an ebuild sets up a variable with a list of relative paths to $D of files that should be skipped for various checks ... so with slmodem, we'd have like: QA_EXEC_STACK=usr/sbin/slmodemd usr/sbin/slmodem_test if, in the future, we need to add an ignore list for TEXTRELs, we'd use QA_TEXTRELS= This becomes tricky when looking at tests across all CHOSTs. What holds true for one arch defiantly is not the case for others. This could be done via the profiles, perhaps - package.qa, something like package.mask/use/keywords: net-dialup/slmodem QA_EXECSTACK=... QA_TEXTRELS=... -- Kevin F. Quinn signature.asc Description: PGP signature
