Hello, I read this sentence on B.3.4 of the eups manual. My use case is that I have the stack accessible through CVMFS, which is great, but I now want the sims distrib on top of it, which is not installed in CVMFS. I set load the LSST config and then add a local path to EUPS_PATH with the ups_db created there.
[ 2/69 ] doxygen 1.8.5 (already installed) done.
eups distrib: You don’t have permission to assign a global tag b1748 in /cvmfs/lsst.in2p3.fr/software/linux-x86_64/lsst-v11.0/ups_db
so cfitsio is more recent than the CVMFS stack version, and thus is correctly downloaded. But doxygen is recognized as installed in the stack, and thus this fails as the code wants to write to the corresponding ups_db. Is this write access really needed in such a case where precisely the package is recognized as installed and ready to be used? And why not use the write access to the local repository if the remote one is not accessible, if indded there is a need to watermark somehow the db of installed packages from the stack?
I think it’s a bug in EUPS (or lack of a feature?).
When EUPS sees a new tag on the server, it tries to tag the product in question. But I think the way tagging is implemented, it must reside in the same ups_db where the product is declared, unless it’s a “user tag” (i.e., your username, or a tag of the form “$USER:something” (I think, I never use this latter form – @RHL will know) ). So this will fail if the product’s database directory is not writable.
Workarounds I could think of:
Copy everything from the CVMF stack to a writable directory, and then point your EUPS_PATH there.
Modify EUPS by changing the if statement that tests writability, and just return instead of throwing an exception. The fact the tag is missing will not be an issue (dependencies are looked up by version, and I presume you won’t explicitly be setup-ing the low-level stuff like doxygen).
Try overlaying a UnionFS filesystem over CVMFS, to gain writability.
Thanks @mjuric, I guess I am still unclear about your very first sentence (apart from the fact that it does look like a bug to me!) : eups writes down (already installed) so it recognized the package in the CVMFS eups_path and matched the tag as identical there and in the server. So why does it need to tag it again, and why would setup fail if the package to be set up is in a non writeable distro place? Of course you are right that I would not eups setup doxygen… but I am still baffled by the intended logic.
Thx for the pointer to the code, I will raise the issue there.
Let me try to explain it better – I think the issue is a combination of two things:
EUPS tags have to live in the same ups_db where the product is declared
When EUPS does installs, it checks the server for all tags a particular product has, and then tries to tag the local copy with them.
So, imagine you already have doygen 1.8.5 installed, and that it was installed with a tag b1500 (I don’t know exactly which tag is in the CVMFS distro). But then when you install sims, EUPS may see that doxygen 1.8.5, in addition to b1500 has (on the server) some additional tags (e.g., b1800, and definitely sims). So it tries to apply those tags to the installed product, and fails (because the directory is not writable).
I think it may be the case that it just blindly applies all the tags (i.e., it tries to apply even the tags that already exist) – that is something that we could fix. But even then, it would want to write any new tags into the products dir (that is not writable). That part requires a more complicated fix (it’s a “missing feature” I obliquely referred to in the previous reply).
ok, thanks.So the difference with the cfitsio case in my initial post is that cfitsio 3360.lsst4 is not in the cvmfs repoditory, and thus eups happily downloads it and puts all the tags locally. But doxygen is the same version, so eups does not download it, but then if the tags are different it tries to add the tags remotely instead of locally. If the tags had been the same in the server and in the CVMFS, would the problem still have occurred?
so I guess one question is : why not also download locally same versions but with different tags. Maybe that would amount to reinstalling the whole stack, I don’t know.
Doxygen is the same version, so it doesn’t download it. But tags are different so it tries to add the tags that it found on the server, to the local (read-only) directory.
I am not sure (don’t know how it’s coded up right now); but that is a problem we could fix relatively easily (just check if the tag exists before trying to write it). Except that this – having identical tags on the server and locally – virtually never happens in a typical situation where you’re using eups distrib install to install new versions; every build will add a new set of tags (the b in the tag name stands for “build”), so there will always be new tags. And that may require some re-engineering to handle (though @RHL or @price should weigh in when they get a chance; I may be overblowing the difficulties).
And yes, if you try to download/build everything to a writable stack, it’s equivalent to a reinstall from scratch.
Re user tags: They are declared in your ~/.eups directory [Warning: due to work by developers whose initials are not rhl there’s stuff in there that looks like a cache but isn’t. I never had the heart to fix all that stuff]. User tags are your user name, or something declared as a user tag in your ~/.eups/startup.py file, e.g.
hooks.config.Eups.userTags.append(“tmp”)
The rhl:tmp form is used to refer to my tmp tag.
The other complication is that the afore-mentioned developer invented a second way to store “system” tags. So things are a mess – but we could add externally-stored tags if needed. Certainly whining rather than aborting seems reasonable.