# Why is eups distrib needing write access to a product stack and database? **URL:** \ **Category:** Support\ **Created:** [January 22, 2016, 9:18am UTC](https://www.rubin.community/t/why-is-eups-distrib-needing-write-access-to-a-product-stack-and-database/497 "2016-01-22T09:18:37Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![johannct](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/johannct/32/2174_2.png) [@johannct](https://www.rubin.community/u/johannct)\ **Post date:** [January 22, 2016, 9:18am UTC](https://www.rubin.community/t/why-is-eups-distrib-needing-write-access-to-a-product-stack-and-database/497/1 "2016-01-22T09:18:37Z")
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. I get : cohen@port-jct:~/lsst/dm/stack/lsst\_sims$ eups distrib install lsst\_sims -t sims [1/69] cfitsio 3360.lsst4 done. [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? ---
**Author:** ![mjuric](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/mjuric/32/31_2.png) [@mjuric](https://www.rubin.community/u/mjuric)\ **Post date:** [January 22, 2016, 9:41am UTC](https://www.rubin.community/t/why-is-eups-distrib-needing-write-access-to-a-product-stack-and-database/497/2 "2016-01-22T09:41:49Z")
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](https://github.com/RobertLuptonTheGood/eups/blob/master/python/eups/Eups.py#L2134), 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](http://unionfs.filesystems.org) filesystem over CVMFS, to gain writability. ---
**Author:** ![johannct](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/johannct/32/2174_2.png) [@johannct](https://www.rubin.community/u/johannct)\ **Post date:** [January 22, 2016, 10:16am UTC](https://www.rubin.community/t/why-is-eups-distrib-needing-write-access-to-a-product-stack-and-database/497/3 "2016-01-22T10:16:13Z")
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. ---
**Author:** ![mjuric](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/mjuric/32/31_2.png) [@mjuric](https://www.rubin.community/u/mjuric)\ **Post date:** [January 22, 2016, 10:45am UTC](https://www.rubin.community/t/why-is-eups-distrib-needing-write-access-to-a-product-stack-and-database/497/4 "2016-01-22T10:45:54Z")
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). ---
**Author:** ![johannct](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/johannct/32/2174_2.png) [@johannct](https://www.rubin.community/u/johannct)\ **Post date:** [January 22, 2016, 11:08am UTC](https://www.rubin.community/t/why-is-eups-distrib-needing-write-access-to-a-product-stack-and-database/497/5 "2016-01-22T11:08:33Z")
ok, [thanks.So](http://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? For reference here is the eups list output: cohen@port-jct:~/lsst/dm/stack/lsst\_sims$ eups list cfitsio 3360.lsst3 b1710 b1711 sims\_development b1713 fe\_test[/cvmfs/lsst.in2p3.fr/software/linux-x86\_64/lsst-v11.0] b1716 b1712 b1694 b1731 v11\_0 w\_2015\_40 current sims[/cvmfs/lsst.in2p3.fr/software/linux-x86\_64/lsst-v11.0] fe\_test2 qserv[/cvmfs/lsst.in2p3.fr/software/linux-x86\_64/lsst-v11.0] b1701 b1700 b1709 b1728 b1725 b1724 sims\_2\_1\_0 2015\_09 v11\_0\_rc3 w\_2015\_39 3360.lsst4 sims[/home/cohen/lsst/dm/stack/lsst\_sims] sims\_2\_1\_2 sims\_2\_1\_3 fe\_test[/home/cohen/lsst/dm/stack/lsst\_sims] qserv\_2015\_11 qserv\_latest dax\_latest b1802 w\_2015\_47 b1809 qserv-dev b1828 b1849 w\_2016\_03 b1781 b1843 qserv[/home/cohen/lsst/dm/stack/lsst\_sims] b1825 dax\_2015\_11 v11\_1\_rc1 b1817 w\_2015\_50 b1812 b1856 b1852 b1842 b1854 b1790 b1791 w\_latest cohen@port-jct:~/lsst/dm/stack/lsst\_sims$ eups list doxygen 1.8.5 sims b824 b1630 n20150327\_b949 b780 b1731 w\_2015\_22 w\_2015\_40 b660 b1100 b261 opsim\_3\_3\_0 opsim\_3\_3\_1 opsim\_3\_3\_2 b858 qserv-dev b1232 b1231 b701 b182 sims\_2015\_06\_18 b1701 b1700 maf\_0\_3 b1259 b1709 b1203 test b1421 b1541 2015\_01 2015\_04 2015\_05 2015\_06 2015\_07 v9\_2-rc1 2014\_09 2015\_03 b376 2014\_08 2015\_08 2015\_09 b1327 w\_2015\_30 w\_2015\_33 w\_2015\_35 b1226 w\_2015\_36 w\_2015\_39 w\_2015\_38 b1539 b1710 b1711 b1712 b1713 b1716 webserv\_1 b1491 b801 b1454 b1153 b1412 sims\_2016\_06\_26 b1419 b1551 v11\_0 2014\_10 2014\_11 2014\_12 b604 w\_2015\_26 b601 sims\_2\_0\_1 sims\_2\_0\_0 t20141107\_b449 w\_2015\_29 b609 b1565 w\_2015\_37 maf\_1\_0\_1 t20150915-b1692 b1687 v9\_1\_1 b750 b551 current b512 b513 t20150914-b1689 t20150914-b1688 b299 v11\_0\_rc2 v11\_0\_rc3 b1657 v11\_0\_rc1 sims\_2015\_05\_30 b1109 sims\_2015\_06\_23 2015\_02 t20150421\_b1109 fe\_test b949 b944 b1499 b345 sims\_w\_2015\_30 n20150416\_b1100 b991 b1471 b1476 sims\_2015\_07\_18 webserv\_2 b1643 b1486 b1641 b449 t20150914-b1690 b1597 v10\_1 v10\_0 b1647 b1490 b1592 b1215 b974 v10\_1\_rc3 b1505 b1468 b1506 b1501 deprecated\_db\_access b1503 b337 b1182 maf\_1\_0\_0 b539 b1267 b531 t20141205\_b531 b1175 b1171 b1679 b1677 b1675 b427 b437 sims\_2\_1\_0 sims\_development b1326 b1693 b1323 b1614 v10\_1\_rc2 b1207 v10\_1\_rc1 b1694 b1108 b1690 sims\_2015\_06\_18b b1692 b1192 b759 v9\_2 v9\_1 b173 b1191 b176 b245 b649 b1105 b1104 b1660 b641 b879 maf\_1\_0\_2 fe\_test2 b1665 v3\_2\_1 n20150419\_b1104 qserv maf0\_2 b1062 t20141208\_b539 b1728 b1683 b557 maf\_1\_1 b992 b1216 b1725 b1724 b1688 b1689 b330 maf\_0\_2\_2 b792 b598 b1288 b1289 b163 b751 b710 b658 b652 b650 b842 setup ---
**Author:** ![johannct](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/johannct/32/2174_2.png) [@johannct](https://www.rubin.community/u/johannct)\ **Post date:** [January 22, 2016, 11:10am UTC](https://www.rubin.community/t/why-is-eups-distrib-needing-write-access-to-a-product-stack-and-database/497/6 "2016-01-22T11:10:19Z")
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. ---
**Author:** ![mjuric](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/mjuric/32/31_2.png) [@mjuric](https://www.rubin.community/u/mjuric)\ **Post date:** [January 22, 2016, 6:29pm UTC](https://www.rubin.community/t/why-is-eups-distrib-needing-write-access-to-a-product-stack-and-database/497/7 "2016-01-22T18:29:08Z")
> [@johannct](#): > > 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. Right! > [@johannct](#): > > 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. 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. > [@johannct](#): > > If the tags had been the same in the server and in the CVMFS, would the problem still have occurred? 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. ---
**Author:** ![RHL](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/rhl/32/25_2.png) [@RHL](https://www.rubin.community/u/RHL)\ **Post date:** [January 22, 2016, 7:01pm UTC](https://www.rubin.community/t/why-is-eups-distrib-needing-write-access-to-a-product-stack-and-database/497/8 "2016-01-22T19:01:04Z")
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.