Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Fri, 22 Jun 2012 19:29:15 +0100
David Leverton wrote:
> Ian Stakenvicius wrote:
> > Technically it could, but the issue here would be what you are going
> > to do with a has_version check on an IUSE_RUNTIME dep -- the package
> > should do filesystem-identical installs no matter what status of
> > IUSE_RUNTIME flags, so whatever one would do with a has_version
> > check would have to not change any part of the build or
> > installation.
>
> In principle it would be used for more or less the same thing as it
> would in a dependency, i.e. check whether the runtime-only
> dependencies for that feature are satisfied - the difference being
> that the package can specify arbitrary if-yes and if-no behaviours,
> rather than just "fail the dependency resolution" or not. (Modulo
> the problem being discussed in this subthread, that a "no" answer
> isn't reliable.)
>
> For example, some tool used during the build might have a "slow" mode
> that always works, and a "fast" mode that requires some other program
> to be installed and that has to be requested explicitly. So the
> package that uses the tool might want to do something like
>
> src_compile() {
> if has_version dev-util/buildtool[fast]; then
> buildtool --fast
> else
> buildtool
> fi
> }
And that particular example should be perfectly valid, to be honest.
There is just a little risk that fast mode wouldn't be used when it
could.
Of course, it's quite unlikely that such an option was actually based
on runtime dep...
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Marien Zwart wrote: Possible solutions: a) automatically rewrite the dep as postscript? ( app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) There may be more than one version of docmangler, with a postscript flag with different effects (IUSE_RUNTIME or full IUSE, different dependencies). That means this kind of rewriting would have to be done based on the dependencies of the docmangler installed at the time this package gets built, which seems like entirely too much magic, and... To clarify, I meant rewrite the dep in docmangler itself, and not necessarily on disk in the VDB or wherever, just in memory when parsing it. But as I said, I don't like that idea anyway, I just mentioned it for completeness. b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make sense in that case to disallow them in !foo-style conditionals in the dependencies of the package itself, as that could cause similar paradoxes) this seems generally impossible, as the same USE flag may be IUSE_RUNTIME in only some versions of docmangler. True. We could declare that in situations like that the developer just needs to be more careful, but then it's not that much better than c) c) don't address it in the spec itself, and require people to manually write the dep in the blocker form if it's required I would be in favor of leaving this up to the writer of the coolapp ebuild, especially as if docmangler is currently using a "full" USE flag for postscript this is already currently broken. Well, in theory if it's a normal USE flag then disabling it should actively remove the Ghostscript support from docmangler, even if Ghostscript happens to be installed, but maybe it doesn't always work out that way.
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Ian Stakenvicius wrote:
Technically it could, but the issue here would be what you are going
to do with a has_version check on an IUSE_RUNTIME dep -- the package
should do filesystem-identical installs no matter what status of
IUSE_RUNTIME flags, so whatever one would do with a has_version check
would have to not change any part of the build or installation.
In principle it would be used for more or less the same thing as it
would in a dependency, i.e. check whether the runtime-only dependencies
for that feature are satisfied - the difference being that the package
can specify arbitrary if-yes and if-no behaviours, rather than just
"fail the dependency resolution" or not. (Modulo the problem being
discussed in this subthread, that a "no" answer isn't reliable.)
For example, some tool used during the build might have a "slow" mode
that always works, and a "fast" mode that requires some other program to
be installed and that has to be requested explicitly. So the package
that uses the tool might want to do something like
src_compile() {
if has_version dev-util/buildtool[fast]; then
buildtool --fast
else
buildtool
fi
}
Re: [gentoo-dev] [RFC] gcc-native-flags() proposal addition to toolchain-funcs.eclass
On wo, 2012-06-20 at 17:56 +0200, viv...@gmail.com wrote: > #409471 "dev-python/pypy-1.8-r1 CFLAGS=-march=native fails to > compile" > https://bugs.gentoo.org/show_bug.cgi?id=409471 Thanks, but currently I do not think we quite need this: I do not think we should use a whitelist of known-working flags for pypy, and rather than blacklisting known-broken flags I am optimistic about just getting them fixed upstream reasonably quickly. And I hope we're done with these for the time being, until another cpu or gcc version comes along. If more bugs like this surface and we can't get support added by upstream reasonably quickly I'll see about using this to fail early, though. -- Marien Zwart
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On do, 2012-06-21 at 20:05 +0100, David Leverton wrote:
> 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
> should REQUIRED_USE be re-verified:
>
> a) for every dep resolution
> b) when the package is involved in the resolution for some other reason
> (not necessarily being reinstalled, just when the resolver has some
> reason to look at it)
> c) something else?
>
> I think b) should be sufficient (and probably easier to implement), but
> is there any reason why it wouldn't be?
I would still prefer for the resolver to not treat such packages
specially at all, and to just deal with USE flag changes explicitly the
same way they're dealt with for "normal" packages/flags, just skipping
the actual rebuild and reinstall steps (just updating the vdb). This
sidesteps problems like this one completely. If the package manager
folks think they can safely do something smarter here that might be
nice, but the feature still seems useful (in reducing the number of
silly rebuilds) and far easier to understand without such magic.
This also means things like has_version checks work exactly like they do
right now.
> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of
> package B being disabled, but it's unlikely to be useful. To make this
> more concrete, a fictional but vaguely plausible example:
>
> app-text/docmangler:
>
> # links to poppler to handle PDFs, and can use Ghostscript for
> # PostScript support if available
> IUSE="postscript"
> IUSE_RUNTIME="postscript"
> DEPEND="app-text/poppler"
> RDEPEND="${DEPEND}
> postscript? ( app-text/ghostscript )"
>
> app-misc/coolapp:
>
> IUSE="doc"
> # if Ghostscript is installed, docmangler uses it for both
> # PostScript and PDF files, but Ghostscript misrenders our PDFs
> DEPEND="doc? ( app-text/docmangler[-postscript] )"
>
> Here, the [-postscript] dep would force the user to disable that flag,
> but it wouldn't do much good because Ghostscript would still be
> installed. This doesn't happen with regular USE flags because (if the
> ebuild is written correctly) disabling the flag removes the feature even
> if its dependencies happen to be installed.
>
> Possible solutions:
>
> a) automatically rewrite the dep as
> postscript? ( app-text/ghostscript )
> !postscript? ( !app-text/ghostscript )
There may be more than one version of docmangler, with a postscript flag
with different effects (IUSE_RUNTIME or full IUSE, different
dependencies). That means this kind of rewriting would have to be done
based on the dependencies of the docmangler installed at the time this
package gets built, which seems like entirely too much magic, and...
> b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
> sense in that case to disallow them in !foo-style conditionals in the
> dependencies of the package itself, as that could cause similar paradoxes)
this seems generally impossible, as the same USE flag may be
IUSE_RUNTIME in only some versions of docmangler.
> c) don't address it in the spec itself, and require people to manually
> write the dep in the blocker form if it's required
I would be in favor of leaving this up to the writer of the coolapp
ebuild, especially as if docmangler is currently using a "full" USE flag
for postscript this is already currently broken. It seems coolapp should
not be building the pdfs, or should be deleting them after they're
built, rather than forbidding the user from having a docmangler that can
create pdfs (as presumably not *all* generated pdfs are corrupt).
I really think this GLEP should be purely about reducing silly rebuilds
in packages where it makes sense to USE-depend on them with a flag set,
or where an already popular flag can be used to pull in some obvious
packages. I think something like "suggested" dependencies can be used to
solve a slightly different problem, and perhaps we could have those too,
but let's leave those for later.
--
Marien Zwart
Re: [gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev
On 22/06/2012 07:40, Ciaran McCreesh wrote: On Thu, 21 Jun 2012 23:01:15 +0200 Michał Górny wrote: Just a short note as it seems some confusion arises lately: Ciaran McCreesh is not a Gentoo dev and his words don't represent the position of Gentoo development team. Right. Doesn't that make me more important than you? https://lwn.net/Articles/501815/ To Exherbo? Probably
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/06/12 12:48 AM, Zac Medico wrote: > On 06/21/2012 02:32 PM, David Leverton wrote: >> Michał Górny wrote: >>> But in the current form, the spec doesn't allow passing >>> IUSE_RUNTIME flags to has_version() so we're on the safe side >>> :P. >> >> True. Do we want to keep it that restrictive? > > Shouldn't has_version allow any atom that would be allowed in > *DEPEND? Technically it could, but the issue here would be what you are going to do with a has_version check on an IUSE_RUNTIME dep -- the package should do filesystem-identical installs no matter what status of IUSE_RUNTIME flags, so whatever one would do with a has_version check would have to not change any part of the build or installation. I could see it being of use within pkg_configure(), though; ie, emerge - --config pkg should then be able to reliably set up default configs based on the runtime installs. However, that's the only place I can picture it being viable. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/kdmIACgkQ2ugaI38ACPBtsQEAs1Ak9JQnDFt4XuG/4ZfYGfH2 u92QpchtCGHhYbERx1wA/3AyghQuEv8WZ2iIfXoW9zWnelutj5fdqF4adSjMwf9x =0XPN -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Killing UEFI Secure Boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/06/12 08:24 PM, Richard Yao wrote: > On 06/21/2012 06:51 PM, Rich Freeman wrote: >> we're a DISTRO - we integrate and ship what upstream gives us... > > RHEL is a distribution, but I understand that RedHat does a great > deal of upstream programming and is also upstream for some things. > Do you consider it to be inappropriate for us to play a larger role > in both upstream development and as upstream ourselves? > As a gentoo developer in general? Absolutely not. Through discussion on this list specifically? possibly. :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/kbQEACgkQ2ugaI38ACPDCrAEAquDX0hrTUufGqXhSG2Cv+yLU bmw3WpMa17OHSmbZ+3QA/Am2K80tHFGDA7uklTUm6Lxe8wynVRTNrmpD93qTlJ4R =gO47 -END PGP SIGNATURE-
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On Fri, Jun 22, 2012 at 8:45 AM, Zac Medico wrote: > On 06/21/2012 11:12 PM, Michał Górny wrote: >> On Thu, 21 Jun 2012 22:32:34 +0100 >> David Leverton wrote: >> >>> Michał Górny wrote: But in the current form, the spec doesn't allow passing IUSE_RUNTIME flags to has_version() so we're on the safe side :P. >>> >>> True. Do we want to keep it that restrictive? >> >> I've added that to the spec but I'm not sure if we're not going too far >> with this. >> >> Now I'm seriously seeing downside of this solution and starting >> thinking about making them auto-enabled when deps are satisfied. > > The funny part is that this could recurse, if you call has_version > a[a-runtime-flag], which depends on b[b-runtime-flag], which depends on > c[c-runtime-flag] and so on... > > I suspect that we'd be better off with a less restrictive spec, and > without this "auto-enabled" thing. I deleted autouse in like 2006, please don't bring it back ;p -A > -- > Thanks, > Zac > >
Re: [gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev
Am Freitag 22 Juni 2012, 04:12:48 schrieb Sylvain Alain: > Amen to that too, but can you post the actual comments that he said ? > SMTP Error "552 Message too large" -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
