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 09-25-2012, 04:20 PM
Michał Górny
 
Default Optional runtime dependencies via runtime-switchable USE flags

On Tue, 25 Sep 2012 17:00:07 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 25 Sep 2012 12:43:00 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
> > Could you please elaborate on what kind of problems may arise ? The
> > proposal seems pretty simple and sane to me: PM only has to switch the
> > useflags that are IUSE_RUNTIME in his installed packages db after
> > installing the deps and without triggering a rebuild of said package.
>
> a) How do we provide a good user interface for it? It took an awful lot
> of experimenting to get the exheres-0 suggestions user interface to be
> good, and it requires quite a bit more information from the package
> side than this proposal is providing. We want to avoid a REQUIRED_USE
> here...

Who is we? I believe REQUIRED_USE is one of the features which will be
available thanks to staying compatible with USE flags instead of
reinventing the wheel.

> b) How is consistency checking to be done? Related, what happens when a
> runtime switch introduces a dependency that then requires a non-runtime
> rebuild of the original package?

Then the package is rebuilt. Where's the problem? Handling of
REQUIRED_USE is not perfectly user friendly but it works.

> c) How do we deal with flag? ( cat/dep[foo] ) or flag? ( >=cat/dep-2.1 )
> cases where cat/dep[-foo] or =cat/dep-2.0 is installed and flag is off?
> From experience, quite a few places where you'd want to use suggestions
> will break if their suggested package is installed but doesn't meet
> version or use requirements.

Er, you mean how to deal with an optional dependency which is not
enabled at all?

--
Best regards,
Michał Górny
 
Old 09-25-2012, 04:25 PM
Ciaran McCreesh
 
Default Optional runtime dependencies via runtime-switchable USE flags

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

On Tue, 25 Sep 2012 12:19:21 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> > a) How do we provide a good user interface for it? It took an awful
> > lot of experimenting to get the exheres-0 suggestions user
> > interface to be good, and it requires quite a bit more information
> > from the package side than this proposal is providing. We want to
> > avoid a REQUIRED_USE here...
>
> Standard USE flag interface. This doesn't need anything special. Why
> will a user care if the flag doesn't trigger a package rebuild?

One of the big selling points of suggestions is displaying them to the
user in a useful way (i.e. not via a bunch of einfo messages). If
you're not planning to allow for that, then you're losing a primary
benefit.

> > b) How is consistency checking to be done? Related, what happens
> > when a runtime switch introduces a dependency that then requires a
> > non-runtime rebuild of the original package?
>
> flag needs to be dropped from IUSE_RUNTIME, so the rebuild would
> occur.

Uh, you're requiring ebuilds to ensure consistency of every
possible configuration of the entire tree?

> > c) How do we deal with flag? ( cat/dep[foo] ) or flag? (
> > >=cat/dep-2.1 ) cases where cat/dep[-foo] or =cat/dep-2.0 is
> > installed and flag is off? From experience, quite a few places
> > where you'd want to use suggestions will break if their suggested
> > package is installed but doesn't meet version or use requirements.
>
> Use flag deps are dealt with identically to the way they are now. the
> only difference , again, is that the package doesn't get re-emerged.
> The VDB would still update imo as if the package did get re-emerged
> (ie: USE and RDEPEND would update), to handle the use flag change
> info in metadata but from what I can tell nothing else would need to
> be touched.

So such packages would just break at runtime?

> > However, addressing these probably isn't enough, since this is
> > just the things we had to think about for SDEPEND-style
> > suggestions... There are likely to be things I've not thought of
> > specific to this method that won't crop up until someone tries to
> > deliver a decent implementation. This isn't a trivial feature.
>
> ..it really is. It piggy backs entirely on the current USE
> implementation, and only skips triggering rebuilds because the
> files-on-disk for a package don't need to change.

It's only trivial if you don't try to do anything with it...

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

iEYEARECAAYFAlBh2xgACgkQ96zL6DUtXhGyFwCfYnK+RGbE+b R1Y53t/X3P7UKb
OW4An3fjTeXsXaksDTSAwf/yENunCGpC
=bWvu
-----END PGP SIGNATURE-----
 
Old 09-25-2012, 04:30 PM
Ciaran McCreesh
 
Default Optional runtime dependencies via runtime-switchable USE flags

On Tue, 25 Sep 2012 18:20:06 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> Who is we? I believe REQUIRED_USE is one of the features which will be
> available thanks to staying compatible with USE flags instead of
> reinventing the wheel.

Yes, but the REQUIRED_USE wheel is square, and gives a *very* bumpy
ride to users. It also isn't particularly easy for developers.

> > b) How is consistency checking to be done? Related, what happens
> > when a runtime switch introduces a dependency that then requires a
> > non-runtime rebuild of the original package?
>
> Then the package is rebuilt. Where's the problem?

The problem is in implementing that correctly... It's certainly doable,
but it's not entirely trivial, depending upon how you're doing
resolution.

> Handling of
> REQUIRED_USE is not perfectly user friendly but it works.

Like a square wheel, yes.

> > c) How do we deal with flag? ( cat/dep[foo] ) or flag?
> > ( >=cat/dep-2.1 ) cases where cat/dep[-foo] or =cat/dep-2.0 is
> > installed and flag is off? From experience, quite a few places
> > where you'd want to use suggestions will break if their suggested
> > package is installed but doesn't meet version or use requirements.
>
> Er, you mean how to deal with an optional dependency which is not
> enabled at all?

I mean the *entire* thing I wrote.

--
Ciaran McCreesh
 
Old 09-25-2012, 04:40 PM
Ian Stakenvicius
 
Default Optional runtime dependencies via runtime-switchable USE flags

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

On 25/09/12 12:25 PM, Ciaran McCreesh wrote:
> On Tue, 25 Sep 2012 12:19:21 -0400 Ian Stakenvicius
> <axs@gentoo.org> wrote:
>>> a) How do we provide a good user interface for it? It took an
>>> awful lot of experimenting to get the exheres-0 suggestions
>>> user interface to be good, and it requires quite a bit more
>>> information from the package side than this proposal is
>>> providing. We want to avoid a REQUIRED_USE here...
>
>> Standard USE flag interface. This doesn't need anything special.
>> Why will a user care if the flag doesn't trigger a package
>> rebuild?
>
> One of the big selling points of suggestions is displaying them to
> the user in a useful way (i.e. not via a bunch of einfo messages).
> If you're not planning to allow for that, then you're losing a
> primary benefit.
>

Must've missed that. I don't much care about showing things about
optional program interation to users on emerge. In fact I see that as
being pretty well useless. Use flag descriptions via metadata.xml ,
though, are *MUCH* more useful and imo suited entirely to this.

(so again, standard use flag interface


>>> b) How is consistency checking to be done? Related, what
>>> happens when a runtime switch introduces a dependency that then
>>> requires a non-runtime rebuild of the original package?
>
>> flag needs to be dropped from IUSE_RUNTIME, so the rebuild would
>> occur.
>
> Uh, you're requiring ebuilds to ensure consistency of every
> possible configuration of the entire tree?

No, only on a per-atom basis. Maybe I didn't understand what it is
you're referring to here. Could you elaborate the issue you are
forseeing with a verbose example?



>>> c) How do we deal with flag? ( cat/dep[foo] ) or flag? (
>>>> =cat/dep-2.1 ) cases where cat/dep[-foo] or =cat/dep-2.0 is
>>> installed and flag is off? From experience, quite a few places
>>> where you'd want to use suggestions will break if their
>>> suggested package is installed but doesn't meet version or use
>>> requirements.
>
>> Use flag deps are dealt with identically to the way they are now.
>> the only difference , again, is that the package doesn't get
>> re-emerged. The VDB would still update imo as if the package did
>> get re-emerged (ie: USE and RDEPEND would update), to handle the
>> use flag change info in metadata but from what I can tell nothing
>> else would need to be touched.
>
> So such packages would just break at runtime?
>

Again, you lost me. The package is still added to the emerge list
same as always, and its dependencies (based on USE) are evaluated same
as always. The package just doesn't REBUILD, because a rebuild would
not result in any change-on-disk.

If there are conflicts in the emerge list then these would be reported
just like if IUSE_RUNTIME wasn't used at all...??


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

iF4EAREIAAYFAlBh3nIACgkQ2ugaI38ACPCilwD9HbOgxa99t0 pRPI/wt4f6zvFT
Lsjc140u+i15NIcatM8A/1tTC6LLIIFTBma13I0au9rdFRC9C5+oqTPI3bGpf3bx
=0ebw
-----END PGP SIGNATURE-----
 
Old 09-26-2012, 01:49 AM
Duncan
 
Default Optional runtime dependencies via runtime-switchable USE flags

Ciaran McCreesh posted on Tue, 25 Sep 2012 17:30:19 +0100 as excerpted:

> On Tue, 25 Sep 2012 18:20:06 +0200 Michał Górny <mgorny@gentoo.org>
> wrote:
>> Who is we? I believe REQUIRED_USE is one of the features which will be
>> available thanks to staying compatible with USE flags instead of
>> reinventing the wheel.

Umm... if I read the preceding posts correctly, you missed his intent
there. He's not saying it'll be unavailable to be used in the
implementation, he's saying we don't want to repeat the experience of the
"bumpy ride" (see below) that required use is, for the user, in a new
implementation.

> Yes, but the REQUIRED_USE wheel is square, and gives a *very* bumpy ride
> to users. It also isn't particularly easy for developers.

Umm... perhaps pentagonal, the physics of a square wheel... <shudder>.

But yes, as a user who has had to resolve REQUIRED_USE related problems a
number of times recently, a *very* bumpy ride for the user, it often is!
Definitely agreed there.

And also agreed with the implication, that we want to avoid a similarly
bumpy-ride implementation here.

(Implimentation-wise, IMO the problem with REQUIRED_USE is often how the
ebuild used the REQUIRED_USE, something I'm hopeful it'll improve over
time as devs get a bit more used to how REQUIRED_USE works and design
ebuild functionality around it, not triggering the double-uses where they
can be avoided without seriously impairing the choices exposed by USE
flags in the first place, and a better REQUIRED_USE implementation is
certainly a challenge, but it's equally certainly an extremely bumpy ride
for the user, as it is today.)

>> > b) How is consistency checking to be done? Related, what happens when
>> > a runtime switch introduces a dependency that then requires a
>> > non-runtime rebuild of the original package?
>>
>> Then the package is rebuilt. Where's the problem?
>
> The problem is in implementing that correctly... It's certainly doable,
> but it's not entirely trivial, depending upon how you're doing
> resolution.
>
>> Handling of REQUIRED_USE is not perfectly user friendly but it works.
>
> Like a square wheel, yes.

Pentagonal (or at least rounded corners on the square... tho of course
then there's patent issues!), but agreed.

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

Thread Tools




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

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