New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DUB does not follow XDG Base Directory Specification #341
Comments
This is the only thing I found for /home (from http://linux.die.net/man/7/hier):
I couldn't find any evidence of that statement being true so far and its the first time I hear of ".local". It also doesn't "install" in the sense of a system installation of programs. Maybe he can clarify or provide a reference? |
Additional quote from http://www.pathname.com/fhs/pub/fhs-2.3.html#HOMEUSERHOMEDIRECTORIES:
Using "~/.dub/..." seems to be perfectly in compliance with this. |
Linux Specification are describes on freedesktop
pathname is a global specification for unix based system |
Hm I see. But that's just for the X desktop, with which DUB doesn't have anything to do - or not? |
That is some rules which programs should to follow to have a cohesive system as dub write file into this system it should follow these rules. Even git follow these rules. little more info:
but for config file they should to go to Thank you for listening to me. |
OK I clarified a bit with @bioinfornatics, this specification defines some environment variables that are meant to override program directories. Eg:
This was introduced in 2010 to give some flexibility to system administrators, since the home directory became too crowded in some situations, or with too much data. |
Git seems to write a single file
Since DUB doesn't really "install" anything, it merely caches the packages and build results. Regarding those environment variables. I've not seen them defined on any system so far. Are they defined system wide, or just within the X session? If the latter is the case, then it wouldn't really be a good idea to use them. |
From what I understand, if it these variables happen to be defined, then it replaces the |
That's what I also understood. But if they are only defined inside of the X session, that would mean that DUB would potentially operate on different folders depending on if it's run inside or outside of an X session. |
yes exactly but they are not define by default an echo and definitely using look on stackoverflow with a similar tool pip from python world :-) |
Somebody else brought this up recently. I think it'd be a good idea to move this directory, but don't know how disruptive it would be to existing installs. |
In particular the |
I don't know. For libraries it doesn't make sense at all, IMO. There are no ABI guarantees. Even with the same compiler/architecture, the library could have been compiled in multiple possible ways, so that we'd have to make the name unique (similar to the build directories), thus cluttering the directory with opaque versions of the same library. This also wouldn't work on Windows in an analogous way. For binaries it could make sense to some degree, but please not by default either. Binaries will often need resource files that they expect in their proximity, which would break unless explicitly handled somehow. It would also be a strange side effect to suddenly invoke a different version of a program after a simple "dub build". All in all, this would be resurrecting the old "install" command, or at least the underlying idea. There are some threads and tickets about this with a number of doubts about such an approach. This is clearly stepping into OS package manager territory. IMO, the important aspect of this is to separate configuration from downloaded packages and build output files. This doesn't just apply to XDG, but also to Windows, where everything except the configuration files should be in "Local" instead of "Roaming". |
I think for a first step towards this this should be pretty simple to implement for someone who knows about these freedesktop environment variables already. The
As for the other features like separating binaries on fetch, shared libraries, etc.: they should be discussed in new issues and not be part of this imo, it would be nice moving the files into standard paths first and then discussing about potential new features |
(EDIT: Original title: DUB does not follow Filesystem Hierarchy Standard)
Criticism heard on IRC.
I guess it's important for distro packaging.
The text was updated successfully, but these errors were encountered: