Fabrice,
> - I think a (git) version tag must only contains digits and dots in
> order to be taken in account cleanly by eups.
This is not the case. Because we aren't doing version
comparisons (other than equality) any more, version strings can be
anything. Just within the stack we have "+" characters as well as
versions including ticket branch names and "g"+hash names.
> That’s why we may call the product xrootd-qserv (instead of xrootd, in
> order to show that your version of xrootd is Qserv-specific, but this
> will require DM agreement) and we must give to the xrootd product a
> version number compliant with eups (like 1.0.0.0, 2.0.0.0, etc) …
I don't think you have to do this. I think you should
name/version the package however AndyH would like, since it has an
existence outside Qserv (unless this code fork is purely for Qserv and
no one else).
> - Could you provide a patch file that we could apply to the xrootd
> version you rely on ? It would allow to use a classical xrootd version
> and patch/build it with eups?
> This step is optional.
This is also a reasonable way to go if this is a custom fork.
> Please note that creating a new package named xrootd-qserv won’t
> impact, for now, the 2014_05 version. But if we don’t change the name
> of the xrootd package and create a new version tag (2.0.0.0) in it, I
> have to test that building 2014_05 will not use the last xrootd
> (2.0.0.0) version but the one used during the distribution build
> (master-gfc9bfb2059).
This all depends on how your distribution stack is setup and
tagged. You can choose to have any set of versions (that is mutually
compatible) in the distribution manifest.
--
Kian-Tat Lim, LSST Data Management, [log in to unmask]
########################################################################
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
|