 |
 |
Daniel Sure! So far I have seen only one such case (but I am sure we will identify more). Cat needs a function: def checkUserExists(self, userName, hostName): I am happy to continue keeping it in cat. Jacek On 01/10/2014 12:43 PM, Wang, Daniel Liwei wrote: > Jacek, > > Okay, thanks for pointing this out. For db and ?logging?, let's make > sure they include only assumptions that make sense for all LSST code > (including Qserv and it's potentially non-LSST, non-science users). Of > course, those specific assumptions need to get in somehow, so maybe cat > has it's own wrapper/plugin for db, and qserv has its own wrapper/plugin > for ?logging?. > > What do you think? > -Daniel > > > On 01/10/2014 11:19 AM, Becla, Jacek wrote: >> Daniel >> >> Qserv also has (or will have) dependencies on three other, relatively >> simple packages from lsst: geom, db and whatever package logging ends up in. >> >> Jacek >> >> >> On 01/10/2014 10:05 AM, Daniel L. Wang wrote: >>> Hi Fabrice, >>> >>> My vision of qserv is that some time part-way through construction, a >>> sysadmin will be able to install qserv via yum (RHEL/Fedora) or apt >>> (Debian/Ubuntu). By then, I hope that all dependencies will be included >>> in both RHEL and Ubuntu. The only dependencies not included yet are: >>> * xrootd (qserv-specific changes should be on mainline in ~2 years) >>> * scisql (probably easy to package) >>> * nearly-forgotten lua-related libs >>> Eliminating the problem lua packages is on the roadmap for qserv. Xrootd >>> is already there, and the right version should land soon. I am willing >>> to maintain RPMs for scisql. >>> >>> So the vision is not too far. If we add sconsutils, we would need to see >>> that packaged in .deb or .rpm. The LSST stack has complex versioning and >>> sandboxing requirements that I think are less appropriate for qserv. >>> >>> Indeed, during the hack week, we decided on a directory layout that is >>> somewhat more complex than the LSST layout, so we wouldn't be able to >>> reuse that part of sconsutils. Don't worry about the scons >>> complexity--it is already much simpler than before (though I have not >>> yet cleaned the obsolete parts out). I am also not ruling out Cmake. >>> >>> Can you clarify what functionality you are hoping to get? My instinct is >>> that our needs are so much simpler that whatever redundancy is smaller >>> and simpler than the adaptation needed to use sconsutils. I'd rather not >>> tie any part of the build process to eups, any more than building SWIG, >>> Python, or boost is dependent on eups. >>> >>> Hope this helps, >>> -Daniel >>> >>> >>> On 01/10/2014 12:43 AM, Fabrice Jammes wrote: >>>> Hello Daniel, >>>> >>>> Thanks a lot for your answer on my previous email (cf. [QSERV-L] Some >>>> questions about building Qserv in branch u/danielw/modules1) >>>> >>>> Here's below an usefull answer from Jim Bosch about sconsUtils. >>>> It seems it may be suitable to detect and link Qserv dependencies. >>>> We may use this in order to remove this code from Qserv scons scripts >>>> and lighten them ? >>>> >>>> K.T., could you please give your opinion about sconsUtils use, it >>>> would be very usefull ? >>>> Indeed, it would allow that Daniel and I to fit to LSST architectural >>>> requirements ;-), and work in the right direction. >>>> >>>> Have a nice day, >>>> >>>> Fabrice >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Re: [QSERV-L] [LSST-data] Some more question about Qserv >>>> packaging with eups. >>>> Date: Thu, 2 Jan 2014 11:14:03 -0500 >>>> From: Jim Bosch <[log in to unmask]> >>>> To: Fabrice Jammes <[log in to unmask]> >>>> CC: Kian-Tat Lim <[log in to unmask]>, qserv-l >>>> <[log in to unmask]>, LSST Data <[log in to unmask]> >>>> >>>> >>>> >>>> I'll limit my responses to questions about sconsUtils, as that's the >>>> only area where I'm really an expert here. >>>> >>>> On Thu, Dec 26, 2013 at 5:02 AM, Fabrice Jammes<[log in to unmask]> wrote: >>>> >>>>> - Do you think Qserv build should relies on sconsutils ? >>>> I don't think this is as important as relying on EUPS; I personally >>>> think Qserv should use sconsUtils only if it is convenient to do so. >>>> It basically provides a configuration system and convenience functions >>>> that allow SCons scripts to be much more concise if the package is >>>> laid out in a certain way and you're willing to commit to creating >>>> .cfg files that describe all of your dependencies. In particular, it >>>> will be most helpful if: >>>> - You have a lot of compiled code; a lot of what sconsUtils provides >>>> is configuration of various compiler build variables (include >>>> directories, library directories, etc). >>>> - You organize the package in the same way as most DM packages, with >>>> doc, include, lib, python, src, and ups directories. >>>> - You use Swig to build Python wrappers for C++ code and need to >>>> build against Swig modules created by dependencies. >>>> >>>>> - Do you thinks sconsutils may be compatible with rpm format ? >>>> Most of it is, and possibly all of it. The part I'd be concerned with >>>> is the need for .cfg files not just for your own package but for all >>>> your dependencies as well. So if your dependencies come from other >>>> rpms, you'd need .cfg files for those too. But they wouldn't need to >>>> be installed with those dependencies; you could package them directly >>>> with Qserv too. Other than that, using sconsUtils with rpm shouldn't >>>> be any different from any other SCons-based build system. >>>> >>>> Jim >>>> >>>> ######################################################################## >>>> Use REPLY-ALL to reply to list >>>> >>>> To unsubscribe from the QSERV-L list, click the following link: >>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> Use REPLY-ALL to reply to list >>>> >>>> To unsubscribe from the QSERV-L list, click the following link: >>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 >>>> >>> ######################################################################## >>> Use REPLY-ALL to reply to list >>> >>> To unsubscribe from the QSERV-L list, click the following link: >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 >>> > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1