Well, spack won't concretize an old version unless it has
preferred=True or you specifically ask for it. So, TBB isn't at any
greater risk than any other package.
If you want to draw the line at 2018.06, then whatever, go ahead.
Be sure to put that in the release notes.
But if it were me, IMO that's unnecessary. I know 2018.04 works fine,
I've been running it for months. For me, I wouldn't exclude revs
unless they were really, really old or broke the build or something.
But that's just me.
--Mark
On 11/05/18 11:57, Benjamin Welton wrote:
Jim,
We are likely okay using either 2019 or 2018.6. So while Dyninst may
pull 2019 (which is apparently a week older than 2018.6), it should be
fine. The real reason I want a limit in the depends_on spec is to make
sure dyninst isn't built with a crazy old version of TBB (and a week
older isn't a big deal).
Go ahead and submit those changes to Spack (assuming everything builds
on your end OK). We will revisit these at a later date if need be.
Mark,
> It's actually a pain to get spack to use a previously installed package
because you have to write a dependency spec that *exactly* matches the
installed version
This is the problem with TBB in specific. While most of Dyninst's
dependencies have very specific recipies that must be built, TBB (at
least as per my understanding) does not. In this case, there is a much
higher chance (which could still be low) of a match to an existing
version. There is a zero chance of a match with an incompatible
version if we specify that we require at least a certain version of
the dependency.
The whole reason I am pushing for this is purely that it eliminates
any chance of a crazy bug being reported by a user that turns out to
be caused by linking to some ancient version of TBB with spack.
As for going forward, I am going to open a dialog with the spack folks
about how to best handle package updates (and best practices for doing
so).
Ben
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}