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-21-2012, 07:05 PM
David Leverton
 
Default Optional runtime dependencies via runtime-switchable USE flags

Michał Górny wrote:

Hello,

A simple solution to a program long-unsolved. In GLEP form.


Just a couple of minor points/nitpicks:

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?


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 )
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)
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

d) something else?

a) is pretty icky IMHO, especially if the flag pulls in multiple
packages. I could live with either b) or c), but b) is less flexible
and c) leaves a potential trap for the unwary. Any opinions?
 
Old 06-21-2012, 07:20 PM
Ian Stakenvicius
 
Default Optional runtime dependencies via runtime-switchable USE flags

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/06/12 03:05 PM, David Leverton wrote:
> Michał Górny wrote:
>> Hello,
>>
>> A simple solution to a program long-unsolved. In GLEP form.
>
> Just a couple of minor points/nitpicks:
>
> [ Snip! ]
>
> 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 ) 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) 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 d) something else?
>
> a) is pretty icky IMHO, especially if the flag pulls in multiple
> packages. I could live with either b) or c), but b) is less
> flexible and c) leaves a potential trap for the unwary. Any
> opinions?
>

I'd say (c) , since IUSE_RUNTIME is not an enforceable state of the
tree and if docmangler is used but fails when ghostscript is installed
anyways, then the DEPEND should specify this regardless of whether the
'postscript' flag (used by IUSE_RUNTIME) is set or whether ghostscript
is in the user's world file.





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/jc+cACgkQ2ugaI38ACPCUOAD+ICKl69MUhUTRj+2HBQ0pNlvo
Bqa5/TmaD0oKIkLi+xgBAIGwynEBXC3dXsG7Amky0OiEUyen41kURyb NLR8FIkT2
=jMZ4
-----END PGP SIGNATURE-----
 
Old 06-21-2012, 07:55 PM
Michał Górny
 
Default Optional runtime dependencies via runtime-switchable USE flags

On Thu, 21 Jun 2012 20:05:46 +0100
David Leverton <levertond@googlemail.com> wrote:

> Michał Górny wrote:
> > Hello,
> >
> > A simple solution to a program long-unsolved. In GLEP form.
>
> Just a couple of minor points/nitpicks:
>
> 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?

Well, I don't understand the difference between a) and b) in your case
but the idea is that REQUIRED_USE should be re-verified if either
enabled USE flag list or REQUIRED_USE changes.

> 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 )
> 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) 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
> d) something else?
>
> a) is pretty icky IMHO, especially if the flag pulls in multiple
> packages. I could live with either b) or c), but b) is less flexible
> and c) leaves a potential trap for the unwary. Any opinions?

Good observation. I think b) is the best solution since forced removal
of random dependencies is a very bad idea (and misuse of blockers).

--
Best regards,
Michał Górny
 
Old 06-21-2012, 08:26 PM
David Leverton
 
Default Optional runtime dependencies via runtime-switchable USE flags

Michał Górny wrote:

On Thu, 21 Jun 2012 20:05:46 +0100
David Leverton <levertond@googlemail.com> 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?


Well, I don't understand the difference between a) and b) in your case


Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and
that I have it installed and then modify one of the flags it uses in my
configuration, but don't run any PM commands. Then suppose I install a
Gnome package. Normally installing a Gnome package wouldn't require the
PM to go anywhere near kde-meta, but being strict about revalidating
REQUIRED_USE would require it to look through every installed package,
just in case any have IUSE_RUNTIME and REQUIRED_USE set, for every
installation command. Is that necessary?


> but the idea is that REQUIRED_USE should be re-verified if either
> enabled USE flag list or REQUIRED_USE changes.

Would that mean the enabled USE flag list should be updated in the VDB
every time REQUIRED_USE is checked, even when the package isn't being
reinstalled? I think it would probably be easier to just recheck
REQUIRED_USE, without trying to figure out whether any of the
IUSE_RUNTIME flags were changed, it's just a question of how eager we
want to be.



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:



Possible solutions:

a) automatically rewrite the dep as
postscript? ( app-text/ghostscript )
!postscript? ( !app-text/ghostscript )
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)

>> 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
d) something else?



Good observation. I think b) is the best solution since forced removal
of random dependencies is a very bad idea (and misuse of blockers).


One case that I forgot to mention before: if some package does something
like


if has_version app-text/docmangler[postscript]; then
# ...
else
# ...
fi

Here, again, the "else" branch can lead to incoherent results as it
can't assume that the postscript flag being disabled means Ghostscript
isn't installed, and this one can't be forbidden by restricting the
allowed dep forms. I think we'd have to just say "don't do that then"....
 
Old 06-21-2012, 08:41 PM
Michał Górny
 
Default Optional runtime dependencies via runtime-switchable USE flags

On Thu, 21 Jun 2012 21:26:26 +0100
David Leverton <levertond@googlemail.com> wrote:

> Michał Górny wrote:
> > On Thu, 21 Jun 2012 20:05:46 +0100
> > David Leverton <levertond@googlemail.com> 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?
> >
> > Well, I don't understand the difference between a) and b) in your
> > case
>
> Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and
> that I have it installed and then modify one of the flags it uses in
> my configuration, but don't run any PM commands. Then suppose I
> install a Gnome package. Normally installing a Gnome package
> wouldn't require the PM to go anywhere near kde-meta, but being
> strict about revalidating REQUIRED_USE would require it to look
> through every installed package, just in case any have IUSE_RUNTIME
> and REQUIRED_USE set, for every installation command. Is that
> necessary?

No, of course not. Otherwise, every package manager run would
practically require it to re-validate all packages in the tree
(possibly not only installed ones).

Package manager must ensure the flags are valid when package is
in the graph. I would think of IUSE_RUNTIME as a last-step action where
packages were in the graph for rebuild already but the rebuild is
disabled as being unnecessary.

> > but the idea is that REQUIRED_USE should be re-verified if either
> > enabled USE flag list or REQUIRED_USE changes.
>
> Would that mean the enabled USE flag list should be updated in the
> VDB every time REQUIRED_USE is checked, even when the package isn't
> being reinstalled? I think it would probably be easier to just
> recheck REQUIRED_USE, without trying to figure out whether any of the
> IUSE_RUNTIME flags were changed, it's just a question of how eager we
> want to be.

No, the USE flag list in vdb may be updated every time the package gets
into the graph with changed runtime flags. I don't consider that
necessary, however. Just a nice backwards compatibility feature for
other applications looking at vdb.

> >> 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:
>
> >> Possible solutions:
> >>
> >> a) automatically rewrite the dep as
> >> postscript? ( app-text/ghostscript )
> >> !postscript? ( !app-text/ghostscript )
> >> 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)
> >> 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
> >> d) something else?
>
> > Good observation. I think b) is the best solution since forced
> > removal of random dependencies is a very bad idea (and misuse of
> > blockers).
>
> One case that I forgot to mention before: if some package does
> something like
>
> if has_version app-text/docmangler[postscript]; then
> # ...
> else
> # ...
> fi
>
> Here, again, the "else" branch can lead to incoherent results as it
> can't assume that the postscript flag being disabled means
> Ghostscript isn't installed, and this one can't be forbidden by
> restricting the allowed dep forms. I think we'd have to just say
> "don't do that then"....

Well, as I see it restricting is more of a policy than a technical
requirement. 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.

--
Best regards,
Michał Górny
 
Old 06-21-2012, 09:32 PM
David Leverton
 
Default Optional runtime dependencies via runtime-switchable USE flags

Michał Górny wrote:

No, of course not. Otherwise, every package manager run would
practically require it to re-validate all packages in the tree
(possibly not only installed ones).

Package manager must ensure the flags are valid when package is
in the graph. I would think of IUSE_RUNTIME as a last-step action where
packages were in the graph for rebuild already but the rebuild is
disabled as being unnecessary.


That's what I thought, was just making sure we're on the same page.


No, the USE flag list in vdb may be updated every time the package gets
into the graph with changed runtime flags. I don't consider that
necessary, however. Just a nice backwards compatibility feature for
other applications looking at vdb.


'K


Well, as I see it restricting is more of a policy than a technical
requirement.


As long as we're clear on which it is, and what restrictions if any the
PM can/should impose...



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?
 
Old 06-22-2012, 04:48 AM
Zac Medico
 
Default Optional runtime dependencies via runtime-switchable USE flags

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?
--
Thanks,
Zac
 
Old 06-22-2012, 05:04 AM
Doug Goldstein
 
Default Optional runtime dependencies via runtime-switchable USE flags

On Thu, Jun 21, 2012 at 2:42 AM, Michał Górny <mgorny@gentoo.org> wrote:
> On Thu, 21 Jun 2012 08:30:24 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>
>> On Thu, 21 Jun 2012 09:29:49 +0200
>> Michał Górny <mgorny@gentoo.org> wrote:
>> > On Wed, 20 Jun 2012 18:24:33 +0100
>> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>> > > On Wed, 20 Jun 2012 19:11:33 +0200
>> > > hasufell <hasufell@gentoo.org> wrote:
>> > > > On 06/20/2012 07:07 PM, Michał Górny wrote:
>> > > > > Please read the rationale. Again. The whole thing. Three
>> > > > > times.
>> > > >
>> > > > Please read my suggestions. Again. The whole thing. Three times.
>> > >
>> > > Can we all agree to just stop this and just restrict the arguing
>> > > to being between SDEPEND and DEPENDENCIES? Cheers.
>> >
>> > You just volunteered to write portage patches. Cheers.
>>
>> Both were already implemented in Paludis, if you're looking for a
>> reference implementation to try it out. There are also examples of
>> use of SDEPEND in the old kdebuilds, and of DEPENDENCIES in Exherbo. I
>> can give you a small patch to turn SDEPEND on for an EAPI if you like
>> (it's just a one line addition to the EAPI definition file).
>
> Wait, did I just write to exherbo ml? No, don't think so. 'Implemented
> in Paludis' doesn't work here. We're discussing Gentoo features,
> and official package manager in Gentoo is portage. If you don't believe
> me, check out the docs.
>
> --
> Best regards,
> Michał Górny

I would recommend the two of you step away from this thread and
discussion for a day or two and come back to it with a fresh look at
the suggestions and the code that's available and then we can move on
getting this into an EAPI from there.

--
Doug Goldstein
 
Old 06-22-2012, 06:12 AM
Michał Górny
 
Default Optional runtime dependencies via runtime-switchable USE flags

On Thu, 21 Jun 2012 22:32:34 +0100
David Leverton <levertond@googlemail.com> wrote:

> Michał Górny wrote:
> > No, of course not. Otherwise, every package manager run would
> > practically require it to re-validate all packages in the tree
> > (possibly not only installed ones).
> >
> > Package manager must ensure the flags are valid when package is
> > in the graph. I would think of IUSE_RUNTIME as a last-step action
> > where packages were in the graph for rebuild already but the
> > rebuild is disabled as being unnecessary.
>
> That's what I thought, was just making sure we're on the same page.
>
> > No, the USE flag list in vdb may be updated every time the package
> > gets into the graph with changed runtime flags. I don't consider
> > that necessary, however. Just a nice backwards compatibility
> > feature for other applications looking at vdb.
>
> 'K
>
> > Well, as I see it restricting is more of a policy than a technical
> > requirement.
>
> As long as we're clear on which it is, and what restrictions if any
> the PM can/should impose...
>
> > 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. It
doesn't prove any practical use except for the above case so it may be
a better idea to just forbid it completely...

--
Best regards,
Michał Górny
 
Old 06-22-2012, 06:45 AM
Zac Medico
 
Default Optional runtime dependencies via runtime-switchable USE flags

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.
--
Thanks,
Zac
 

Thread Tools




All times are GMT. The time now is 07:32 AM.

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