[Nottingham] Gentoo portage tips

[Robert Davies]

On Sunday 31 Aug 2003 17:48, Philip Scott wrote:

> > 1)  Avoid emerge later wanting to 'downgrade' a package, previously
> > emerged from unstable ie. ~x86.  I probably need a few eg) from DRI
> > HOWTO.
>
> Well, I think the idea is that you only use the unstable keywords for the
> odd few packages you are really intrested in having the 'bleeding edge' of
> ;) If you emerge everything with ~x86, you're just asking for trouble 8*)

Sometimes you need (or at least it's recommended) to use a ~x86 version of a 
package, ironically emerg-ing with everything bleeding edge is no problem 
with portage (just sling ACCEPT_KEYWORDS="~x86" in /etc/make.conf).

The issue is, when you have have added only one or two ~x86 packages like   
'ACCEPT_KEYWORDS="~x86" emerge xfree-drm', and then (months?) later run 
'emerge -u -p world',  and emerge wants to downgrade those packages.

In FAQ GF5: What are masked packages?  
http://forums.gentoo.org/viewtopic.php?t=33534 it actually discusses a 
package.unmask file, but unfortunately "There is currently no way for 
ACCEPT_KEYWORDS to "stick" to a package or packages, so it is somewhat 
complicated to mix stable and unstable packages." so it appears this is still 
a pain.  Could try unmasking the installed unstable package and hope it 
overrides the KEYWORD ~x86 in the ebuild.

Looking at http://www.gentoo.org/doc/en/portage-manual.xml it's possible to 
pin a specific version of a package, by an '=' line in /var/cache/edb/world, 
which would be short-term workround, though '>=' is actually what's really 
wanted.

Anyone actually tried to solve this?

> > 3. Install XFree-DRM and configure direct rendering
>
> No idea about this, I'm afraid :)

If you don't do Nvidia it's for H/W 3D,  
http://www.gentoo.org/doc/en/dri-howto.xml.

> > A weakness of portage was that packages installed to fulfill
> > dependancies, might not get updated after security alerts, unless you
> > specifically have emerged them.
>
> I don't quite understand you here.. Is there any package system whereby
> packages get automatically updated after security updates?

Yes, it's a standard feature of most distro's with online updates, sometimes 
because only security or critical bugs are fixed in name of stability.  
apt-get, SuSE YOU, Mandrake's and Red Hat's updater will all leave your 
system patched for known vulnerabilities, even Window's Update does this.

Obviously the administrator needs to run the check for updates, but that can 
be automated.  Portage cuts corners, emerge -u only upgrades packages it 
thinks you are 'interested in', as listed in the file /var/cache/edb/world, 
and their dependancies.  But this means shoujld a library or utility be 
vulnerable, to trigger emerge -u world to update it, the distro would have to 
change  all the application dependancies, and force a re-compile of those, 
even if it's uncessary, needless to say totally impractical.

> As far as I can
> tell, the system doesn't differentiate between packages specifically
> emerged and packages installed as dependancies. And if you're really
> worried, emerge --update should upgrade all of your installed packages to
> the latest (and theoretically) more secure versions..

That's the problem, 'emerge -u' only updates the packages you *specifically* 
installed and their required dependancies.  Specifically not the 'libfoobar'  
or utility 'snafu' which you never head of, which was installed to satisfy 
dependancies of the programs you're interested in.  See your installed 
version is already adequate according to the ebuild's of everything in the 
world file.

> And if you can't be
> bothered with that, just re-emerge any package found to be at risk to grab
> a patched version. It'd be silly to have to update *every* dependncy of a
> package if only an update of that package is required.. You'd end up
> recompiling libc every time a securty hole was found in sendmail ;)

Yes, it would be silly and you don't need to do it.  Thanks to shared 
libraries and dynamic linking, only a vulnerable library and any statically 
linked executables using it need updating to solve a library vulnerability.  
An application vulnerability has never ever meant that underlying 
non-vulnerable libraries it links with need updating.

The problem with 'just re-emerge any package found to be at risk' is that the 
responsibility is with the admin, rather than the automatic package update 
system.  Computer's are supposed to work for us, not us for them!

Rob