Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Praise for the Gentoo team and users
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
bammbamm808
Guru
Guru


Joined: 08 Dec 2002
Posts: 323
Location: Hawaii

PostPosted: Mon Feb 03, 2014 5:13 am    Post subject: Praise for the Gentoo team and users Reply with quote

Just wanted to say that updates are smoother than ever, problems to glitches easier than ever to find in the forums and bugzilla. Thanks to everyone who makes it possible for me to routinely update my system and little or no downtime from a usable system. If I can maintain a usable Gentoo system for years, anyone can. Huzzah!!
_________________
Asus m5a99x Evo Rev 2
Phenom II X4 965 BE
8Gb DDR3
Geforce GTX 460
Etc....
Back to top
View user's profile Send private message
tw04l124
Veteran
Veteran


Joined: 03 Oct 2006
Posts: 1656
Location: A t z e l, lower austria

PostPosted: Mon Feb 03, 2014 2:31 pm    Post subject: Reply with quote

Code:
emerge @preserved-rebuild
is one of the biggest steps in forward direction.

My system was hardly ever unuseable after that.

also
Code:
eselect read news new
when I remember it right is also a step in the right direction.

It works much more smooth recently without any mayor breakages.

Thanks for the good work
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Mon Feb 03, 2014 5:11 pm    Post subject: Reply with quote

tw04l124 wrote:
Code:
emerge @preserved-rebuild
is one of the biggest steps in forward direction.

:evil:
Code:
acoswt@PrimaPratica ~ $ grep FEATURES /etc/make.conf
FEATURES="-config-protect-if-modified -preserve-libs"

... oh wait... :idea:
Code:
acoswt@PrimaPratica ~ $ emerge --ignore-built-slot-operator-deps=y blahblah


I just love being able to build precisely what I want to build, no more, no less! :P

And... obviously... if what I build happens to break something I was caring about, it simply means that I am actually not caring a damn about it.
_________________
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3039
Location: The Peanut Gallery

PostPosted: Mon Feb 03, 2014 6:08 pm    Post subject: Reply with quote

@aCOSwt: interesting. Why not have the --ignore.. in EMERGE_DEFAULT_OPTS, since you've turned the feature off?

As for main point, yeah Gentoo has only got more robust over time. It indicates the validity of having variant approaches to the same problem, imo ("defence in depth"?). revdep-rebuild as back-up for @preserved-rebuild is what I use with update and I've seen less breakage over the years.

Wondering if we need anything extra to support your use-case, aCOSwt: don't think so given EMERGE_DEFAULT_OPTS, but it might be nice to document the approach on the website, and perhaps add a short-flag for it.
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Mon Feb 03, 2014 10:38 pm    Post subject: Reply with quote

steveL wrote:
@aCOSwt: interesting. Why not have the --ignore.. in EMERGE_DEFAULT_OPTS, since you've turned the feature off?

:D Hmmm... because... I... hmmm... am not dogmatic! :wink:
I mean... I can accept this feature not turned off when emerging the ck-sources for example... :)
steveL wrote:
it might be nice to document the approach on the website, and perhaps add a short-flag for it.
++
_________________
Back to top
View user's profile Send private message
sk3l
Tux's lil' helper
Tux's lil' helper


Joined: 14 Jul 2012
Posts: 76
Location: CT USA

PostPosted: Tue Feb 04, 2014 1:13 pm    Post subject: Reply with quote

tw04l124 wrote:
Code:
emerge @preserved-rebuild
is one of the biggest steps in forward direction.


Agreed.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3039
Location: The Peanut Gallery

PostPosted: Tue Feb 04, 2014 8:01 pm    Post subject: Reply with quote

aCOSwt wrote:
Hmmm... because... I... hmmm... am not dogmatic! ;)

Lul.
Quote:
I mean... I can accept this feature not turned off when emerging the ck-sources for example... :)

OK, I'm just trying to get it clear in my head before we document how to use it, and perhaps add support for it. If you have the feature (preserved-rebuild) off, portage will not track lib linkage, nor keep old libs attached to new packages until they're no longer needed (so revdep-rebuild is essential.) Ah I see, the --ignore.. is orthogonal to that. It's about tracking the SLOT of the dependency, so at resolution time it means "trigger a rebuild if the SLOT of the dep has changed since this pkg was installed" (the default setting, which we're turning off.)

So really they're two separate things: the second switch may be useful as and when: I'd imagine we don't want that on a "-uD --changed-use world" but it might be one to drop in on the cli when installing piecemeal. In any case, it's down to the user to add it as and when, so it could do with a shorter flag which is simple enough. It's not something I'd want to add to extraOpts in /etc/update but its presence there or in EMERGE_DEFAULT_OPTS has to be coped with (ie we need to check for it, and counter it during world resolution, or alternatively document it and say "don't do that.")

Hmm that implies a switch to turn it off as well, so -I for the =yes option doesn't really work, and don't think we have any other switches available (-i = install to world, ie no -1 to emerge). Of course we could leave it with -I for yes, and if you need to add no use the long option; you're kinda outta the supported use-case if so. But I'd like to have a better flag. What do you think?

It's a switch used to speed up dependency resolution, really: I used to use pkgcore (and emerge=smerge) for that. ;(
Back to top
View user's profile Send private message
dencar
Tux's lil' helper
Tux's lil' helper


Joined: 23 Dec 2003
Posts: 108
Location: Noosa, Australia

PostPosted: Tue Feb 04, 2014 11:05 pm    Post subject: Reply with quote

Quote:
also
Code:
eselect read news new
when I remember it right is also a step in the right direction.


I tried that and got the error
Code:
Can't load module read


It should be
Code:
 eselect news read new


Nitpicking I know.
_________________
dencar
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Wed Feb 05, 2014 9:09 am    Post subject: Reply with quote

steveL wrote:
If you have the feature (preserved-rebuild) off, portage will not track lib linkage, nor keep old libs attached to new packages until they're no longer needed (so revdep-rebuild is essential.)

True.
steveL wrote:
Ah I see, the --ignore.. is orthogonal to that.

Exactly!
steveL wrote:
the second switch may be useful as and when: I'd imagine we don't want that on a "-uD --changed-use world"

Yes of course --ignore in this particular case of the world set does not make much sense to me.
If I decide to --update or --emptytree the entire world then it means that I am ready to update everything and want everything on my system fully functional after such an operation. => It's typically a case in which I will not --ignore.
I would even less want to --ignore in that particular case that such an operation will trigger the build of packages I certainly know nothing about and even ignore their existence on my system and their impact on other packages. => I want all these things to remain transparent to me => I won't --ignore when dealing with the world set.

However, my typical use case of the --ignore (besides emerging the ck-sources, that was just meant for joking) is when dealing with subsets of world.
On my system, I manage a couple of portage's sets. These sets are made of packages I know and need for one particular reason. The packages I push in one set are put together for the sole sake of some coherence I want to ensure.
And the coherence I want to ensure is necessarily different from the coherence Gentoo-Devs have to guarantee.
I perfectly understand that Gentoo-Devs simply cannot push a new icu and just leave libreoffice broken on the users' system. That is, I believe, the point that govern's Gentoo-Devs understanding of coherence. Fair enough.

But on my system, my understanding of coherence must rule. If I make the effort to create a specific set, put icu in this set and not put libreoffice in this set (while perfectly aware that libreoffice depends on icu) then when I decide to emerge --update @thisparticularset, I mean that I want icu to be updated and not libreoffice.
So that is my particular use case of the --ignore-built-slot-operator-deps option. When dealing with subsests of world.

No need to have user defined sets to realize the dramatic advantage of this option.
You still get users who (sometimes rightly) proceed to an emerge --emptytree @system then follow with an emerge --emptytree @world
I do not think that these users are happy to rebuild packages that are not explicitly members of the system set as part of the first operation as these will necessarily be rebuilt by the second operation. This leading to kyriads of perfectly useless rebuilds.
Hence a more sensible approach in this particular case :
1/ emerge --emptytree --ignore-built-slot-operator-deps=y @system
2/ emerge --emptytree @world

These particular use cases also demonstrate that one should not be dogmatic with the use of this option and not push it as part of EMERGE_DEFAULT_OPTS.

OK, these are the most immediate needs that come to my mind but there are certainly plenty other use cases.
steveL wrote:
I'd like to have a better flag. What do you think?

I love the functionnality... How I call it... well... you know... I'm a *NIX user so... I got used to not actually mind. :wink:
I tend to be fed up by shortcuts and have always preferred typing literally emerge --oneshot, --update, --emptytree, --unmerge... to memorizing the shortcuts. When I become fed up with long command lines, I make an alias... or worse... : bind -m emacs '"\e[26~": "emerge -pv --deep --update --changed-use world\n"' :D

Anyway thank you, steveL, for caring about this.
_________________
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3039
Location: The Peanut Gallery

PostPosted: Thu Feb 06, 2014 5:15 pm    Post subject: Reply with quote

Ahh thanks acos, that makes much more sense now. So the flag stops changes in SLOTs for things we're emerging from triggering rebuilds in other packages, and adding them to the set of packages to build -- as well as saying "don't add a package to the initial set where you would normally, because its dependency has changed SLOT."

IOW it works both ways, or just the first? I think there is a difference, when it comes to having things like -D, though as you said in those circumstances it's not a good idea to use the flag. Equally they might be the same thing, and I'm just confuddled ;)

In any event it definitely is a useful flag to expose, as you said when doing a specific set, or @system followed by @world, so if you can think of a switch I'll add it. We can use something like --ibs if we can't find a letter (as well as triggering off the long one.) Or --IBS, or another one you prefer.

I'm not fussed about what flag, but having read your explanation, I definitely want to start using it, and there is no way on earth I'm typing all that in every time. Quite often I use update to try out a couple of combinations before I build, and I like having short flags to choose from: really long ones simply break my focus (often I forget the exact combination of words as well, since I don't use them that often.) --ibs or --IBS as "ignore built slots" both work for me: the latter might be a good precedent if we're going to start shortening emerge options that come in handy (ie if it's --CAPS it's an abbreviated emerge one) but equally it means a shift. You use the flag, so I'd like your opinion.

Hmm might be nice to add it whenever we're emerging a specific set that isn't world? (Configurable option, off by default.)

edit to add: after all that it appears to be a flag you only ever turn on, and can use -I? Help! ;-)
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Fri Feb 07, 2014 12:40 pm    Post subject: Reply with quote

steveL wrote:
So the flag stops changes in SLOTs for things we're emerging from triggering rebuilds in other packages, and adding them to the set of packages to build -- as well as saying "don't add a package to the initial set where you would normally, because its dependency has changed SLOT."

Exactly! Well... at least that is how I expect it to impact. :)
steveL wrote:
IOW it works both ways, or just the first?

:? Both ? First ? What do you mean ?
steveL wrote:
Hmm might be nice to add it whenever we're emerging a specific set that isn't world? (Configurable option, off by default.)

Absolutely! That is my opinion and... I share it! :)
Ideally (for me) it should be made default in any case but when @world is concerned. People working with subsets are supposed to know what they do.
steveL wrote:
if you can think of a switch I'll add it. We can use something like --ibs if we can't find a letter (as well as triggering off the long one.) Or --IBS, or another one you prefer.

Fair enough, I told you, I get absolutely no preference.
Oh wait! :idea: Much more simple :

- emerge [options] a.cos(myset.t) symbolizing the emerge of myset without its harmonics (--ignore-built-slot-operator-deps=y)
- emerge [options] ∑ak.cos(k.myset.t) symbolizing the emerge of myset and k harmonics (--ignore-built-slot-operator-deps=n)

Great! I like it! meaningful, simple, readable, obvious!
The other big advantage of this is giving to zac's successors a new way of understanding portage and significantly reduce their work as well as easing stabilization processes!
BTW, all they need to do from now on is to discuss and implement conditions on ak, k and t! 8)

steveL wrote:
edit to add: after all that it appears to be a flag you only ever turn on, and can use -I? Help! ;-)

:twisted:
_________________
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3039
Location: The Peanut Gallery

PostPosted: Sat Apr 05, 2014 2:14 pm    Post subject: Reply with quote

@aCOSwt: OK, added the flag to update git, for your QA pleasure ;) You can view the commit with: git show a367217731d8 in your clone. Or run: git log -p and search for aCOSwt; in less here I used: /aCOS <ENTER>, to search for it just now.

There's been quite a few other changes, and I'm still tweaking --toolchain, so bear with me if it's not exactly right. I haven't documented it yet (nor in fact tested it;) so we can still tweak it.

The basic way to get --ignore-built-slot-operator-deps=y is to add -I to the command flags; you can also turn it on with ---ibs and off (=n, the default) with --IBS (as well as use the full-length variants of course.) It checks for it in EMERGE_DEFAULT_OPTS as well, same as with --jobs|-j.

That may seem a bit counter-intuitive, if you compare -I with --IBS. If you think solely in terms of --ibs then: --ibs=y and --IBS=n.
The -I flag is convenience based on above discussion, and the capital indicates it's not something usual. Other capitalised flags are typically for phases, like -R for revdep, -A for GLSA and -W for kernel modules, which may be all you want done, unless they're emerge flags like -B or -K. Anyhow, like I said it's still in draft mode, so we can tweak it; I saw the -I as being useful, and the common usage of capitals as negative, not so applicable in this context, but still there conceptually, since you're telling emerge to ignore them.

Follow up in the forum thread if you want anything changed, please (the "tweaking --toolchain" post is last in it, atm.) Well unless it's a bug, ofc :)

HTH,
steveL.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum