| 1 |
Alan McKinnon wrote: |
| 2 |
> On 22/09/2015 17:55, James wrote: |
| 3 |
>> Dale <rdalek1967 <at> gmail.com> writes: |
| 4 |
>> |
| 5 |
>> |
| 6 |
>>>> I usually remember --oneshot but if I'm tired or distracted I |
| 7 |
>>>> forget it. |
| 8 |
>> |
| 9 |
>>> To avoid this, I added it to my make.conf. When I *really* want to have |
| 10 |
>>> something in the world file, I can either add it myself or use --select |
| 11 |
>>> on the command line to add it. Result, shouldn't be anything in the |
| 12 |
>>> world file that shouldn't be there. |
| 13 |
>> OK, I'll try this. |
| 14 |
>> I'll add --oneshot to the EMERGE_DEFAULT_OPTS= in make.conf. |
| 15 |
>> |
| 16 |
>> Works great. |
| 17 |
>> |
| 18 |
>>> I sometimes wonder why that isn't the default way. I guess because it |
| 19 |
>>> would confuse folks for a bit and because it has always been that way. |
| 20 |
>> One thing I see, is now you have a system that is full of pkg that do |
| 21 |
>> not update normally. I guess I'm say if you install pakages with --oneshot, |
| 22 |
>> they are not automatically updated, or are they? (discussion). |
| 23 |
>> |
| 24 |
>> 'emerge -uDNv world' is the most common form of update, probably, used |
| 25 |
>> by gentoo users. So how to best ferret out those oneshot packages for |
| 26 |
>> update; and that's if they should be updated.... semantics on that? |
| 27 |
> |
| 28 |
> I think you two have it backwards. |
| 29 |
> |
| 30 |
> The intended workflow is that if you emerge something, you know what it |
| 31 |
> is, you don't have to make further decisions about it and you want it in |
| 32 |
> world. |
| 33 |
> |
| 34 |
> @world, by definition, is the list of packages you want. That plus |
| 35 |
> @system plus all deps constitutes the set of what should be on the |
| 36 |
> system, anything you have not in that set is subject to depcleaning |
| 37 |
> |
| 38 |
> If you are not sure about some package, by all means emerge it with -1. |
| 39 |
> Check it out, verify it, make sure it does what you want then get it in |
| 40 |
> world with emerge -n. Why would you want to have stuff around for |
| 41 |
> extended periods that is not in world? |
| 42 |
> |
| 43 |
> If you have a package that you no longer want (as you know what is in |
| 44 |
> your world right), unmerge it with -C |
| 45 |
> |
| 46 |
> Don't make life difficult for yourself. It's MUCH easier to know what's |
| 47 |
> in world than to try and remember what should be and isn't. |
| 48 |
> |
| 49 |
> |
| 50 |
> |
| 51 |
|
| 52 |
|
| 53 |
For me at least, this way works best. Before I did it this way, if I |
| 54 |
had to workaround a portage block or some other issue, I would forget to |
| 55 |
add -1 and ended up with a world file full of stuff that shouldn't be |
| 56 |
there. By the way, this doesn't effect updating at all, at least it |
| 57 |
doesn't for me. |
| 58 |
|
| 59 |
If say I emerge googleeath and I want to keep it installed and added to |
| 60 |
world, I then emerge it with --select y on the command line and it gets |
| 61 |
added to the world file. Basically, if something gets added to the |
| 62 |
world file, I took a extra step to make sure it got there. It doesn't |
| 63 |
get there by mistake. |
| 64 |
|
| 65 |
Since I've been doing it this way, I have not had a single thing added |
| 66 |
to my world file that I didn't want to be there. For me at least, it |
| 67 |
works. It's just to easy to forget to add that -1. It's not hard at |
| 68 |
all to remember to add --select y when needed tho. If it was something |
| 69 |
you were testing, --select y -n works like a charm. |
| 70 |
|
| 71 |
For my way of thinking, I think having a extra step to add something to |
| 72 |
the world file leads to a cleaner system. I wouldn't set it on a new |
| 73 |
install until I was doing installing all the things I do want tho. |
| 74 |
After I had my usual stuff installed, that -1 would be added. |
| 75 |
|
| 76 |
To each his own tho. |
| 77 |
|
| 78 |
Dale |
| 79 |
|
| 80 |
:-) :-) |
Archives