Re: [Ltib] LTIB: distribute prebuilt host RPM packages (rpm-fs, git, distcc, ...)

[Stuart Hughes]

Gernot Hillier wrote:
> Hi!
> 
> Am 14.05.2010 16:37, schrieb Stuart Hughes:
>>> Therefore I'm seeking for a mechanism to provide an additional dir where
>>> ltib looks for binary RPMS before rebuilding them - exactly like %ldirs
>>> provides a means to add an additional LPP dir.
>>>
>> For the host packages this is not easily doable as describe before.
> 
> Sorry, but I still don't get it. :-(
> 
> Why couldn't LTIB check for the binary RPM for "rpm-fs" and then for the
> others in an additional path defined by .ltibrc (which would be
> writeable for a normal user) and install those instead of recompiling
> them? Just like it is done for %ldirs before downloading stuff from the GPP.

Who/what would install them?
How would you manage/segregate the set of rpms that belong to your
distro on the server and maintain it?

Try it and you'll soon figure out the problem.  As I said it's chicken/egg

> 
> There's surely a mentionable risk that they might not work on each and
> any Linux distribution - however, I'd bet that those basic tools don't
> have too much external dependencies and should run on most recent
> Fedoras, SUSEs, Ubuntus or friends if the versions aren't years away.
> 

You'd be surprised.  rpm-fs alone is not binary portable.  That's the
very first one in the list.


>> So if you know all your hosts are running the same distro, you could
>> come up with a scheme that saves off all the binary rpms and then later
>> you could somehow install these using your script.
> 
> Yeah, that's exactly what I want. Just that I'd love to see a way to
> place them somewhere else besides /opt/ - some place a normal user would
> have access to.
> 

The rpms in /opt are not relocatable, you can't just install them
anywhere, they are built and installed to a given prefix.

>> The real battle you're fighting again is the chicken/egg and security
>> issues of bootstrapping a known environment that can run on and
>> distribution.
> 
> Don't get me wrong: I'm not arguing about general distribution of
> prebuilt RPMs as part of LTIB. This should be done for each distribution
> which would mean a lot of work for sure. It's just about a feature which
> could be rather usable in "controlled" environments like project teams
> where people tend to work in comparable environments.
> 

I get the use case, but on balance it's not worth the effort.  Not at
least in this form.  I have thought about other ways of pre-building the
host stuff, but right now I don't have the time/sponsorship to do that.

> And LTIB itself seems to be the only place where this could be
> implemented taken I don't want to have my script run with sudo rights.
> 

Actually it's only /usr/bin/rpm, /opt/ltib/usr/bin/rpm that have sudo
rights, so another script could leverage that fact.

>> My suggestion would be it's not worth doing this.  If you're using VMs,
>> why not just clone those at a known working starting point.
> 
> Sure, there would be other solutions. It's just about an additional
> feature for speeding up things in enterprise use. Something we could
> probably implement if you would agree that it makes sense... :)
> 

BTW: I should mention that LTIB uses ccache (and can use distcc).  If
your machines were all the same distro, possibly you could distribute
the ccache .cache directory to speed up the build.

Anyhow I digress.  I'd advise using a pre-built virtual machine if
you're doing enterprise distribution.  Another option (again which I had
in the pipeline) was to offer an LTIB server which could scale.  That
way the remote machines don't install LTIB, they're just clients (take a
look at the video here to get an idea of what I mean:
http://zee2seh/site/products-z2rlab/autodocs/z2rlab/z2rlab-intro.html)

Regards, Stuart