On 06/09/13 15:16, Matt Doidge wrote:
> Heya Steve,
>
>>
>> It does. But it would be helpful if you could answer some more questions
>> (I'm sorry to be a bore on Friday afternoon).
>>
>> Anyway, from what you have said, you make a tarball of the UI. Users
>> could then install it on their systems. I assume you do that by taking
>> each newly released binary rpm, unpacking the rpm somehow, and taring
>> the tree with (maybe) a bit of tweaking inbetween. And you put the
>> result in some known location. You also install (untar) said tar balls
>> in a certain location within cvmfs so that some users can directly use a
>> "tarball" release via cvmfs without even resorting to tar. So, my
>> questions are (1) is this what you do (2) what are the "locations" of
>> the products and (3) is this already summarised anywhere? It's all OK,
>> but next you need the vomsdir/vomses bits to complete this idea. So here
>> is my proposal:
>
> I'm off teh clock today, so I'll keep this short, but the answers to
> your questions are:
>
> 1) Yep, that's how it's done.
>
> 2) http://repository.egi.eu/mirrors/EMI/tarball/
> Specifically this tarball:
> http://repository.egi.eu/mirrors/EMI/tarball/cvmfsdevel/
>
> Look also in the grid.cern.ch cvmfs repo.
>
> 3) My documentation is a bit crusty:
> http://www.sysadmin.hep.ac.uk/wiki/EMI2Tarball
>
>>
>> a) I'll take your newest UI tarball, and put it on a system here, and
>> I'll make some process to merge the vomsdir/vomses bits into your work
>> automatically. I'll test it, and then I'll hand the process to you.
>>
>> b) Then you can build it into your standard tarball procedure. There's
>> no point in me getting involved with that (it would get confusing - it's
>> one person's work).
>>
>> So please let me know those locations so I can get cracking.
>
> Hopefully that's enough info. I was going to suggest a workflow where I
> take your stuff and hammer it into the tarballs, rather then you take
> the tarballs and hammer your stuff into it
That makes sense to me too.
> (sorry for being so
> technical),
:-)
Do you (Matt) run Yaim to configure the UI? If so, then site-info.def
and vo.d files ought to work for the yaim configure step after an RPM
install[1] and also your cvmfs and tarball installs.
> but my hands are full of SL6 upgrade, a move to SGE and
> glEXec so if we want this looked at this month it might be best for you
> to take a peek, and we can take this offline.
>
> Cheers, and have a good weekend all,
And you.
Chris
[1] In fact, thinking about this, the Debian way would probably be to
have a package (or possibly packages for each VO), with a "trigger" to
generate the config files. If whatever yaim does is static, you wouldn't
even need the trigger. I suspect one might be able to do this with RPM -
and then we wouldn't even need to run yaim - but lets walk before we try
to run.
Chris
|