[Gllug] Foresight rPath security updates?

[James Laver]

On 2 Apr 2009, at 16:27, j.roberts wrote:

>> Are you using one of the ready-prepared VMs on rBuilder or are you
>> building your own?
>
> Mainly prebuilt

Ah, unfortunately this puts you at the mercy of the appliance maker.  
Frankly, most of them don't know what they're doing. Building with  
rPath properly is hard work and takes time to master.

>> If you're using a ready-prepared one, you should just run an update
>> periodically through conary or RAA.
>
> Well we have tried this, but we have ended up fairly often in  
> dependency
> heel when the base system applies an update which is incompatible with
> what is running on  it (this has happened with Trixbox vms).

Again, see above.

>> If you're building your own, then you'll need to bump packages when
>> they're backported (the easiest way to do this is just to shadow them
>> from the main rPath repository and rebuild them in your repository).
>>
>> I admit there's a little bit much effort involved, however.
>
> Quite so. But we are thinking that this is the only way to deal with  
> the
> problem mentioned above. Hence reluctance to deploy despite other
> advantages.

When it's done right, the rPath system is absolutely brilliant.

The way foresight were doing it when I ceased to be a developer was  
quite genius. They had an interesting label arrangement:

foresight:devel
foresight:contrib
foresight:2-qa
foresight:2

They'd commit all of the recipes they needed in core into devel, this  
would include shadowing stuff from rPath (although in practice, they  
didn't really rely on the rPath repository much, foresight was much  
more updated).

Once they wanted to push it into the 2 series of releases, they'd  
promote everything in the repo to 2-qa and run a build in rMake. Any  
further updates, they'd put into devel, promote to 2-qa and build in  
rMake. When it was deemed stable enough for actual release, they'd  
promote them across to 2 and re-rMake them.

Since rMake builds in a chroot, you can be absolutely guaranteed this  
way that if it builds and if it appears to work, the only problems  
you're going to have are going to be either hardware related or  
software bugs, any building issues will be caught in rMake.

(A side effect of this is that when they move to FL:3 (if they haven't  
already), all they need to do is promote from foresight-devel to  
foresight-3-qa and rebuild. Likewise backporting is made similarly  
easy))

--James
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug