Wol <[email protected]> writes: > On 26/02/2022 22:14, Ramces Tampo-og Red wrote: >> I see. I will be wary of my world file from now on. I'm glad that you >> mentioned this now since I don't have that much packages installed yet >> and I haven't played around with the system enough that there's a chance >> that it might break. Knowing this is really handy since it might not be >> apparent when things that shouldn't be added in the world file are being >> added to the world file. > > If you think you might have been guilty of this, just edit your world > file with vim or whatever, delete everything you don't recognise or you > recognise as having been done for troubleshooting, and save it. It won't > make any difference to your running system. Just be careful not to > delete by accident stuff you really did want (although you could always > re-emerge it). >
Coming from a binary-based distribution, this stuff is just pure magic
to me. I feel like I'm just now learning how to actually manage my
system. This made me think, would it be possible to trim my world file
and sort them into sets? I'm digging the possibility of being able to
only update groups of packages that I want to.
I've been struggling with updates lately since I've emerged qutebrowser
and updates to qtwebengine is brutal to my X200. I haven't set-up distcc
yet and the hard drive in this poor thing isn't enough to cover for a
decently sized ccache.
So I'm wondering whether it would be feasible to just move some of the
contents of the world file into sets and just manage the packages that
way.
> Then try an "emerge --depclean --pretend" and see what would be removed.
> Last time I did that, I then manually -C'd each package in turn - not
> least because I need to update my kernel an d depclean buggers that up
> if you're not careful ... always do an emerge, build new kernel,
> depclean quickly, in that order, with no sync in the middle! Otherwise
> you might end up cursing ...
>
Yeah, I can see why that would be a problem if you did a sync in the
middle.
> The other thing is, (and it's probably already been mentioned,) is make
> sure you know how to use package.use and package.accept. Don't add
> things like ~amd to our global settings, just add them freely for
> VERSIONED stuff in those directories. Then as updates come along, all
> your changes get left behind as "no longer necessary".
>
> I learnt this the hard way, I enabled ~amd for a package that had no
> stable versions, that required a new ~amd version of glibc, that then
> blocked any attempt to update my system! So there was a trail of
> messages on this list as I worked out how to fix the mess :-)
>
> By putting all this stuff in package.accept and package.use, I can keep
> track, and if the file is old it's probably out of date and ripe for
> deletion. I can just move it out the way, try an update, and if it blows
> up look what's in the file I've moved to see what I need to keep and
> what cruft can be deleted.
>
Oh man, I did this once! I added ~amd64 as a global variable and
everything updated. I didn't realize the folly of what I did until I saw
that gcc is being rebuilt. I think I've gone a little bit wiser since
then (hopefully).
> Cheers,
> Wol
>
Thank you for the really helpful tips!
Cheers!
--
. * +
+ Ang kalayaan ay dili gihatag, ini'y giabot.
* + {gopher,gemini}://kalayaan.xyz *
. C4AE 5D53 46A0 01DF 6E92 CB46 92D7 9FBB AB9F 3E37 .
signature.asc
Description: PGP signature
