FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-22-2012, 07:36 AM
Alec Warner
 
Default Optional runtime dependencies via runtime-switchable USE flags

On Fri, Jun 22, 2012 at 8:45 AM, Zac Medico <zmedico@gentoo.org> wrote:
> On 06/21/2012 11:12 PM, Michał Górny wrote:
>> On Thu, 21 Jun 2012 22:32:34 +0100
>> David Leverton <levertond@googlemail.com> 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
>
>
 
Old 06-22-2012, 01:42 PM
Ian Stakenvicius
 
Default 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-----
 
Old 06-22-2012, 04:27 PM
Marien Zwart
 
Default 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
 
Old 06-22-2012, 06:29 PM
David Leverton
 
Default 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
}
 
Old 06-22-2012, 06:39 PM
David Leverton
 
Default 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.
 
Old 06-22-2012, 09:37 PM
Michał Górny
 
Default Optional runtime dependencies via runtime-switchable USE flags

On Fri, 22 Jun 2012 19:29:15 +0100
David Leverton <levertond@googlemail.com> 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
 
Old 09-25-2012, 03:04 PM
hasufell
 
Default Optional runtime dependencies via runtime-switchable USE flags

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is anything holding this back to be reviewed by the council in the
near future?

Do we need an implementation beforehand? Afaik zac said that the
implementation would not be very complicated, so why not vote on this
now/soon?

mgorny?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQYcgXAAoJEFpvPKfnPDWzFEgH/RD7Lvl8Dp16KK+02F7L0y70
rEJ9Syo6lApIg4u6BjhMglHUd3pAZxGJ4VPtQpCdu5BL7cH7wA V3cZY+JF1j+YNV
Qd+gkVfVGJZf/gklza4pSayZluOTx9iqKr6HzPfWSQi6ugEtPG+46hLD4fGu3yr e
z1ndQjZDKy28fbG5p4R4nRDgYWUKkmd981nF8qBLguXuHDw0K3 a5Hqx2l+cLZnc9
yynNX02cYDb3qtRH7QoQczfMnAv0nDIfUdWebuHAUFqFuHgAkg ws9JrzkscGrAfR
/KFQICl4TAwN0zlW69monOO3oMzZRYMsJlfX79W4RXhEmCRobb+ VOLWxu9svCRs=
=Ff4b
-----END PGP SIGNATURE-----
 
Old 09-25-2012, 03:10 PM
Ciaran McCreesh
 
Default Optional runtime dependencies via runtime-switchable USE flags

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 25 Sep 2012 17:04:55 +0200
hasufell <hasufell@gentoo.org> wrote:
> Do we need an implementation beforehand? Afaik zac said that the
> implementation would not be very complicated, so why not vote on this
> now/soon?

Well we can't really compare it to SDEPEND (which is implemented in
Paludis, for kdebuild-1 and exheres-0) without at least a half-arsed
implementation.

Also, speaking as someone who *has* implemented this kind of thing, I
have extreme doubts as to the viability of the proposal. So I'd be
extremely wary of voting in favour of it until we've been able to have
a play with an implementation.

- --
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBhyYMACgkQ96zL6DUtXhGPsQCeN6muE82mJO Pm9aox2zd1r8p0
5scAn3JkHsHGqPkpBJNCH4Nb94zW7b5H
=LMaV
-----END PGP SIGNATURE-----
 
Old 09-25-2012, 03:17 PM
hasufell
 
Default Optional runtime dependencies via runtime-switchable USE flags

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/25/2012 05:10 PM, Ciaran McCreesh wrote:
> On Tue, 25 Sep 2012 17:04:55 +0200 hasufell <hasufell@gentoo.org>
> wrote:
>> Do we need an implementation beforehand? Afaik zac said that the
>> implementation would not be very complicated, so why not vote on
>> this now/soon?
>
> Well we can't really compare it to SDEPEND (which is implemented
> in Paludis, for kdebuild-1 and exheres-0) without at least a
> half-arsed implementation.
>
> Also, speaking as someone who *has* implemented this kind of thing,
> I have extreme doubts as to the viability of the proposal. So I'd
> be extremely wary of voting in favour of it until we've been able
> to have a play with an implementation.
>

sorry?

I don't see an answers to any of my questions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQYcrzAAoJEFpvPKfnPDWztIwH/jXV53rVzF4dAImZbOb/zkD1
MU8JfWnYLirERryoix6lhtvMKlSxSCthU+M0wmKYdQ/Rwo5bqkRrgeSgfLg5xQo+
wn9k6YhiU6a0pWNTpG6WUZM9n6vwXYiqBwTX2QAedaPMCw/SbxQeSeF4bq0XNrRC
jmwUXKO3LhhQDREuSFXg55LqBbx9NeFvoPxUlqOf7lPl0jXlbu 6B0pR5MpxEqysy
IFqglzXMIrguk9u/UxY/Z3lDfDzA1zxI3zgDGUiZ5sVKMtqEg8iDNbdsr9K0Zg0H
Qe6mbAFYj3V0Nb6lA6n2/54KjWzVKl9dGtzGQsjwyfu4IdbZNX3O5qi+4Y2CYck=
=QaMz
-----END PGP SIGNATURE-----
 
Old 09-25-2012, 03:23 PM
Ciaran McCreesh
 
Default Optional runtime dependencies via runtime-switchable USE flags

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 25 Sep 2012 17:17:07 +0200
hasufell <hasufell@gentoo.org> wrote:
> On 09/25/2012 05:10 PM, Ciaran McCreesh wrote:
> > On Tue, 25 Sep 2012 17:04:55 +0200 hasufell <hasufell@gentoo.org>
> > wrote:
> >> Do we need an implementation beforehand? Afaik zac said that the
> >> implementation would not be very complicated, so why not vote on
> >> this now/soon?
> >
> > Well we can't really compare it to SDEPEND (which is implemented
> > in Paludis, for kdebuild-1 and exheres-0) without at least a
> > half-arsed implementation.
> >
> > Also, speaking as someone who *has* implemented this kind of thing,
> > I have extreme doubts as to the viability of the proposal. So I'd
> > be extremely wary of voting in favour of it until we've been able
> > to have a play with an implementation.
>
> sorry?
>
> I don't see an answers to any of my questions.

Really? I thought it was pretty clearly. Yes, you need an
implementation beforehand.

- --
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBhzH4ACgkQ96zL6DUtXhHT2gCgtDFTdPkQ6X 6jCkFzOIaqY+O7
uFQAnRnsznezzmSBha09MrCkRy1/3LZc
=ouSd
-----END PGP SIGNATURE-----
 

Thread Tools




All times are GMT. The time now is 11:55 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org