I am trying to cut a dcache release as we speak but after that , and
catching up for some bugs that came in while I was at a Grid deployment
meeting, I shall be working on a new metapackage and VOMS query
application that should remove the need for perl-Net-SSLeay
For testing at Desy I must admit I built and successfully and used from
DAG I think, in SL 4 64 bit.
I spoke to many grid admins who always supplement SL 3 or 4, 64 bit or
32 bit with the DAG repositories, I also had the impression that this
was standard for the LCG grid as of SL 4. (Its not required for SL3)
Maybe Suggesting DAG repositories will change as SL4 becomes the
standard grid platform with the forthcoming release, I should like to
know. I do know that for LCG Grid current opinion in the order of 32/64
bit support priorities seems not to be a consistent request. For Dcache
both are targets and 64 bit will take priority as our customers seem to
want it more. I think for other node types the order of priority maybe
32 bit 64 bit. Either way I shall try to reduce Dcache as a cause of
these dependencies as soon as I get time and for now I recommend DAG.
Regards
Owen
PS
Please correct me if I'm wrong about DAG repositories.
PPS
We don't have many perl experts, and none in my immediate team so want
to remove all perl dependencies as well, even such well written perl.
On Thu, 26 Apr 2007 11:02:00 -0700 (PDT)
Denice <[log in to unmask]> wrote:
> On Thu, 26 Apr 2007, Michel Jouvin wrote:
>
> > They don't ignore anything, they don't have it for 64-bit and are expecting
> > their application to run in compatibility mode without any 64-bit stuff
> > provided with the app. For me this is a reasonable expectation.
>
> They don't have it for 64-bit because the developers didn't build
> the 64 bit packages where needed. I don't understand either why
> the 64 bit versions of those perl/python packages which include
> shared-library files would not be built.
>
> An example I'm thinking of is perl-Net-SSLeay - the 64-bit
> version of this package is available from non-redhat sources, as is of
> course the src.rpm file. The glite-SE_dcache metapackage requires it,
> but the gLite s/w distribution (external components) only includes
> the 32-bit version of this package. We needed the 64-bit version of
> this package for dCache nodes here, as we do not and will not run
> dCache nodes on 32-bit OS'es.
>
> Perl and python RPMs are no longer platform independent when they include
> and require shared library modules.
>
> So I would be very interested in hearing from gLite people about which
> perl/python packages could not be rebuilt for 64-bit arch. in the
> non-external components of gLite. It sounds to me like the problem is
> being pushed to Scientific Linux, when it could be solved by building
> the 64-bit packages..
>
> cheers,
> denice
>
> > --On jeudi 26 avril 2007 09:54 -0500 "Marc W. Mengel" <[log in to unmask]>
> > wrote:
> >
> >>
> >> I think the issue that folks are concerned about is that they have a
> >> package which is a combination of:
> >> platform-independant python/perl code
> >> binary loadable python/perl module (.so file)
> >> which they cannot run on the 64-bit perl/python because they only have
> >> a 32-bit .so file.
> >>
> >> They seem to be ignoring the possiblity of shipping .so files for
> >> all of the platforms they want to be able run on -- that is you could
> >> have the ix86, the x86_64, and maybe sparc_solaris versions of the .so
> >> with your package so that you could run it all three places...
> >>
> >> Marc
> >>
> >> Jaroslaw Polok wrote:
> >>> Hi Michel
> >>>
> >>> I still fail to understand what problem are you trying
> >>> to solve here ....:
> >>>
> >>> Either the application in question can be ported to
> >>> 64 bit (so no problem ..) or not: then why to run it
> >>> on an 64 bit system in first place ?
> >>>
> >>> SL exists in both 32 and 64 bit variants ...
> >>>
> >>> Cheers
> >>>
> >>> Jarek
> >>>
> >>> __
> >>> -------------------------------------------------------
> >>> _ Jaroslaw_Polok ___________________ CERN - IT/FIO/LA _
> >>> _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _
> >>> _____________________________________ +41_78_792_0795 _
> >>
> >
> >
> >
> > *************************************************************
> > * Michel Jouvin Email : [log in to unmask] *
> > * LAL / CNRS Tel : +33 1 64468932 *
> > * B.P. 34 Fax : +33 1 69079404 *
> > * 91898 Orsay Cedex *
> > * France *
> > *************************************************************
> >
> >
>
> --
> deatrich @ triumf.ca, Science/Atlas PH: +1 604-222-7665
> <*> This moment's fortune cookie:
> <apt> it has been said that redhat is the thing Marc Ewing wears on
> his head.
|
