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-02-2012, 07:44 PM
Fabio Erculiani
 
Default EAPI 5+: split PDEPEND introducing SDEPEND

s/with/on/

--
Fabio Erculiani
 
Old 09-03-2012, 06:44 AM
Duncan
 
Default EAPI 5+: split PDEPEND introducing SDEPEND

Fabio Erculiani posted on Sun, 02 Sep 2012 16:45:12 +0200 as excerpted:

> - If SDEPEND contains USE flags, these are written in stone and cannot
> be changed without a rebuild. This is generally fine for source
> packages, a bit less for binpkgs, but not really a big deal IMO.

This being the case, don't we effectively already have the feature in the
form of default-use? Isn't a USE flag defaulted-on in effect ALREADY a
"suggestion"? That seems to me to be how it's used in practice.

For a new "suggested" mechanism to be actually worth the implementation
cost, I'd /suggest/ that it must allow flipping state without a rebuild.
Otherwise we effectively already have it in the form of default-use, so
what's the point?

Now it's certainly possible to argue that once one sets a global USE
flag, the visibility of default-use "suggests" isn't particularly high,
and that ideally --ask and --pretend with --verbose (and presumably
whatever corresponds in the other PMs) should somehow emphasize "suggest"
state a bit more than simply "it's there, make your own choice" state,
which is arguably what normal use flags are, but that's a PM UI issue,
not a lack of ability to mark "suggests" in the ebuild.

Unless I'm missing something, the information's already expressible in
the ebuild with existing default-use; it just arguable needs a bit more
emphasis in the UI /as/ suggests, because that's what default-use in
effect already IS.

--
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
 
Old 09-03-2012, 07:38 AM
Duncan
 
Default EAPI 5+: split PDEPEND introducing SDEPEND

Fabio Erculiani posted on Sun, 02 Sep 2012 21:38:26 +0200 as excerpted:

> On Sun, Sep 2, 2012 at 9:04 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>>
>> The big issues you're ignoring:
>
> And you call them "big issues"?
> Ah, the "you're ignoring" part looks a bit arrogant, are you short with
> arguments ;-) ?

Observation here, but he looks to have at least /had/ arguments. Your
post OTOH was rather "content free" other than the flaming.

If you can't post anything substantive please just avoid the post
entirely.

--
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
 
Old 09-03-2012, 08:00 AM
Duncan
 
Default EAPI 5+: split PDEPEND introducing SDEPEND

Ciaran McCreesh posted on Sun, 02 Sep 2012 20:04:11 +0100 as excerpted:

> The big issues you're ignoring:
>
> * What to do if a package has an SDEPEND upon cat/pkg[x] and the user
> has cat/pkg[-x] installed, or if another package in the resolution
> depends upon cat/pkg and the user hasn't specified USE=x. Similarly,
> an SDEPEND upon >=cat/pkg-2.1 and the user has cat/pkg-2.0 (which is
> in the same slot as 2.1) installed. The right answer is to force a
> reinstall with [x] / force the upgrade, and for the spec to explicitly
> require this from implementations, but *why* this is the case is
> fairly subtle.

> * What use? blocks in SDEPEND actually mean. Again, there's a right
> answer here: it's for when a particular suggestion requires the base
> package to be built in a particular way.

Reading here, the above "right answers" look self-evident to me, but I'm
assuming the "somebody else did it so it looks simple" principle applies
and I'm simply not seeing the too easy but wrong trap-answers.

It would be quite helpful if you'd briefly describe them as you did the
"right answers", along with (if it's not apparent given both them and
right answers) why they're traps, as well. You mention the significant
work it was to get these right for kbuilds and exherbo down-thread, and
I'd imagine so. But with these "right answers" looking self-evident and
no knowledge of the traps you had to avoid to get to them, it ends up
looking far simpler than I imagine it was, and given that we're
discussing specs for the gentoo solution to the same problem, having
someone explicitly point out what and where the traps are in ordered to
avoid them could be quite helpful indeed.

Thanks. =:^)

--
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 12:44 PM.

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