diakonos 0.8.3 works on x86-macos
Created attachment 125309 [details] app-editors/diakonos
who is the maintainer of diakonos? chase him/her!
I am the author of Diakonos. I'd love to be the maintainer of the e-build, but the forces of the universe have conspired against me for nearly three years now.
ohw great... I see. This package is (unfortunately) not in the main tree at all yet... Apparently pipping assigned this bug to himself for that reason. I think we should find a proxy for you, Pistos, as the ebuild is really trivial, and the updates look pretty much low frequency, right?
Let me know whatever I can do to help. And yes, the updates are very infrequent. Probably just two to four times a year.
I'm willing to be the proxy here. When first starting diakonos, it tells: --- $ diakonos diakonos.conf not found in any of: /usr/local/etc/diakonos.conf /usr/etc/diakonos.conf /etc/diakonos.conf /usr/local/share/diakonos/diakonos.conf /usr/share/diakonos/diakonos.conf ~/.diakonos/ At least one configuration file must exist. Would you like to download one right now from the Diakonos repository? (y/n) --- I'd prefer to have the ebuild installing the default /etc/diakonos.conf, rather than downloading to ~/.diakonos/ at each user's first invocation. Thoughts ?
Earlier versions of Diakonos were just two files: diakonos.rb and diakonos.conf. You mv'ed the conf wherever you liked among some searched spots, among which was /etc. Unfortunately, when they finally got around to updating rubygems enough to let me specify a binary, and I went to make a Diakonos gem, it was (and still is) the case that you can't specify system-wide conf files to go in places like /etc. Not sure if this is by design, oversight, or lack of motivation, or what. Anyway, independent of the gem itself, there is no problem with having the ebuild drop a copy of the default diakonos.conf into /etc. So please proceed.
Created attachment 145982 [details] diakonos-0.8.3.ebuild for main tree This ebuild works for main tree. But the same problem persists in prefix, just being hidden when there is diakonos installed on the host os (ideally being a main gentoo system), because $EPREFIX/etc/diakonos.conf is not searched: ---- $ type diakonos diakonos is hashed (/eprefix/usr/bin/diakonos) $ diakonos diakonos.conf not found in any of: /usr/local/etc/diakonos.conf /usr/etc/diakonos.conf /etc/diakonos.conf /usr/local/share/diakonos/diakonos.conf /usr/share/diakonos/diakonos.conf ~/.diakonos/ At least one configuration file must exist. Would you like to download one right now from the Diakonos repository? (y/n) ---- But now - I have no clue (yet) where best (in the ebuild) and how to patch diakonos source. Pistos, as you're Diakonos' maintainer, are you able to provide a patch/release/whatever and an ebuild eventually for prefix to search "${EPREFIX}/{etc,usr/share}/" instead of "/usr/local/{etc,share}/" please ? Thanks!
Would it be an acceptable solution if I had Diakonos search some environment variable path (e.g. DIAKONOS_CONF_PATH=/etc:/usr/local/share:${EPREFIX}/etc:.....) in addition to its default search path?
Please avoid environment variables whenever possible for normal/default behaviour. It's debatable to use environment variables to control user specific additional behaviour, but again please avoid for default behaviour, and try hard to store such information inside the program somehow (builtin, read files based on installation prefix, ...). Thanks!
I didn't realise this package was far more complicated than I thought at first. But my opinion on this config stuff: Looking at those paths, I really feel like there should be only one path used in Gentoo, which is (${EPREFIX}/etc/diakonos.conf. I don't like it searching in any other locations, since you don't want the app to suddenly start to behave differently. Also, for Prefix we need to be able to control where to look for the config file to ensure no conflicts with host installed copies of diakonos.
Starting at the next version, I can narrow the config locations. Say, exclusively to /etc for global, systemwide config, and ~/.diakonos for user overrides. I've read some of the documentation for EPREFIX, but I don't fully understand whether this is a variable present only during emerge-ence, or if it is always defined on a system (for example, it is empty on my system here). I'm not clear as to how EPREFIX (or any other installation path/prefix/info) can be "passed along" to Diakonos at installation time. I don't believe the rubygems system provides a mechanism for such a transmission, and even so, that implies I need to write an additional little binary that would accept the path string and work with it. Even assuming all this, where is a responsible and respectful application supposed to store such information? Any recommendations for all this?
(In reply to comment #12) > Starting at the next version, I can narrow the config locations. Say, > exclusively to /etc for global, systemwide config, and ~/.diakonos for user > overrides. Ok. > I've read some of the documentation for EPREFIX, but I don't fully understand > whether this is a variable present only during emerge-ence, or if it is always > defined on a system (for example, it is empty on my system here). Please don't rely on EPREFIX in any package: EPREFIX is a Gentoo specific variable, only set in environment inside ebuilds. > I'm not clear as to how EPREFIX (or any other installation path/prefix/info) > can be "passed along" to Diakonos at installation time. I don't believe the > rubygems system provides a mechanism for such a transmission, Can't say either - have never seen rubygems before. > and even so, that > implies I need to write an additional little binary that would accept the path > string and work with it. What exactly do you mean with 'binary' here ? > Even assuming all this, where is a responsible and > respectful application supposed to store such information? Packages using some build mechanism like autotools generate or modify some files during the build and install them along or compile them in. Sometimes we also do modify installed plain text files to exchange "/default/prefix" with "/the/current/eprefix". As ruby packages seem to be plain text files, eventually this could be a way to go - exchange "/etc" with "/the/current/eprefix/etc". One hint for you as package maintainer in this case: Assume your default prefix is "/usr/local", and define the default config file location as "/usr/local/etc/diakonos.conf" in an easy-to-find-and-modify way, so the ebuild can change (or define) it to "${EPREFIX}/etc/diakonos.conf".
let'd first try to get this rolling for gentoo-x86, questionable if it isn't a dup in that case
(In reply to comment #14) > let'd first try to get this rolling for gentoo-x86, questionable if it isn't a > dup in that case Sure. FWIW, recent version of Diakonos have abandoned Rubygems, and now use an install.rb which I have crafted to ease the task of distro package maintainers. It accepts many varied and sundry options to control where things go, including configuration files, and even what sandbox prefix to use, if any. I hope this can speed things along, though honestly, after nearly four years of nothing being done, I've given up on expecting Gentoo to accept Diakonos into the main tree. Even glacial-speed Debian beat Gentoo in this regard. *shrug*
(In reply to comment #14) > let'd first try to get this rolling for gentoo-x86, questionable if it isn't a > dup in that case Dup indeed. *** This bug has been marked as a duplicate of bug 110190 ***
