I would like to install Gitlab (omnibus, from a deb ), where the executables and /etc files go in their standard location, but the rest go in a tree based at /srv/gitlab.
It's not clear to me how to accomplish this modifying the configuration files,since there seem to be so many directories there. Can someone help?
Edit
There is this question:
Data Dir relocation but it only answers part of the question git_data_dir changes the location of git repositories. Since I am ( obviously ) still installing GitLab I can't say what are the exact features, but clearly there is a wiki and issue trackiong and git_data_dir does not cover those, AFAIK. I'm looking for something that moves as much as is possible.
Related
I just unzipped sublime_text_3_build_3143_x64.tar.bz2 and have a nice copy of the sublime_text_3 directory in my downloads folder.
Where is the right place to put this file in Centos? Maybe somewhere in /user/local/?
Also do I create a link to the executable or set a Path?
Just looking for favorite (best?) practices.
As has been pointed out in the linked article in the question comments, /opt is preferred by some, and in fact according to this answer, /opt is where you would locate "unbundled packages". Of course, it also goes on to say that these sorts of packages should also package the binary in a bin subfolder, which Sublime does not, for what that's worth.
If you want to follow best practices, that's probably where you should place the folder. If nothing else, I would assume that any Linux OS that has a package manager for doing upgrades is going to stay well clear of /opt based on what it's used for, which will make sure that something untoward can't happen.
As to whether you would create a symlink or add that folder to the path, I'm not so sure. My own personal philosophy is that the PATH isn't something that needs to have an entry for every application that I install.
My own recommendation would be to create a symlink somewhere that's already in the path and you're good to go. The linked article mentions putting the link in /usr/bin. The Filesystem Hierarchy Standard says of this path:
This is the primary directory of executable commands on the system.
I would take from this that this is an acceptable path to put the symlink in.
In the end, it doesn't matter to Sublime where the folder is placed, since it determines the location of the shipped packages based on where it's binary is located, and the configuration information is always in a known place.
I have been using git for some time now and I feel I have a good handle on it.
I did however, build my first small program as a distribution (something with ./configure make and make install) and I want to put it up on github but I am not sure how to exactly go about tracking it.
Should I, for instance, initialize git but only track the source code file, manpage, and readme (since the other files generated by autoconf and automake seem a bit superfluous)
Or should I make an entirely different directory and put the source files in there and then manually rebuild everything for version 0.2 when it is time?
Or do something else entirely?
I have tried searching but I cannot come up with any search terms that give me the kind of results I am looking for.
for instance initialize git but only track the source code file, manpage, and readme (since the other files generated by autoconf and automake seem a bit superfluous)
Yes: anything used to build needs to be tracked.
Anything being the result of the build does not need to be tracked.
should I make an entirely different directory
No: in version control, you could make a new tag to mark each version, and release branches from those tags to isolate patches which could be specific to the implementation details of a fixed release.
But you don't create folders (that was the subversion way)
should I make an entirely different directory for sources
Yes, you can (if you have a large set of files for sources)
But see also "Makefiles with source files in different directories"; you don't have just one Makefile.
The traditional way is to have a Makefile in each of the subdirectories (part1, part2, etc.) allowing you to build them independently.
Further, have a Makefile in the root directory of the project which builds everything.
And don't forget to put your object files in a separate folder (not tracked) as well.
See also this question as a concrete example.
So, we probably did something we shouldn't have done, but now I wonder how this should typically be handled.
We have a large project with multiple applications which are grouped in different sub-systems. I was working on one specific application which was found in the following subdirectory:
/svnroot/subSystemName/myApp
Since I didn't need the whole SVN, I just did a checkout of that subdirectory.
Some time later, someone else figured that the name of the sub-system wasn't quite right, so he did a svn rename on the directory, so that my application is now found in:
/svnroot/subSystemNewName/myApp
As you might imagine, this causes problems because when I try to do an update for instance, it says "target path does not exist", as it's still looking for the original path.
What am I to do? Is the only solution to do a full checkout again? How should this have been handled in the first place?
PS: I'm on Linux.
svn switch should do the trick. Run svn switch <url_of_new_location> <local_checkout_dir>
My request may look strange but it'd make more sense after I explain why I'm doing it.
So I have my person projects under /path/to/myprojects. Underneath maybe C, Perl, Shell, Tcl, etc. Now I want to put those project groups (C, Perl, etc) under git, but in different location, e.g., /path/to/mygits/.
The reason that I want to do this is that, traditionally I backup my /path/to/myprojects to other locations by rar them first. Since they are all text based, rar them up will yield excellent compression ratio. Now I want to keep the same practice, even I've introduced git. Thus I need to keep the binary git repository out of the way of my text base folder into a separate binary base folder.
All my findings on stackoverflow indicate impossible, or I "have to use submodules which can be quite painful":
Git: Different Working Directory and Repository location,
git repository with folders in different locations,
Add Separate Directories/Projects/Files to Git Repository
However, there is one answer that says it is possible to decouple the git working directory and git repository directory:
how do I change the location of a Git repository
but it says something about git reset --hard which I want to know the details.
Also Using GIT_DIR seems to be another solution.
Anybody can help?
Thanks
Alright, enough waiting, let me answer my own question.
As DCoder has pointed out, the answer is at Can I store the .git folder outside the files I want tracked?.
I.e., there are many git based solutions listed there, all needs some extra
git configuration. You might have to do them if under Windows. However, under Linux, symlinking the .git directory to somewhere else is the easiest and cleanest solution.
After few weeks of struggle i am able to create a medium native package debian package which works well in installation and removing of the package.
As http://www.quietsche-entchen.de/cgi-bin/wiki.cgi/-wiki/CreatingDebianPackages
Debian wiki
http://wiki.debian.org/HowToPackageForDebian http://www.debian.org/doc/manuals/maint-guide/ these are the quite good material for beginners,
I have basic problem, in updating the package all the files data.tar.gz are updated by default.
I want only few files to get updated in the data.tar.gz based on a key variable stored in all the files.
After the unpacking that is executing preinst script, all the files in data.tar.gz are already updated..
my idea was to take back up of the files intially before upgrading the package, and check key variable in files.. if the key variable is greater than the current variable replace it..
which means i am writing a simple backup script.. and executing in the postinst file..
i donot think this is good idea.. and more over limitations in dash script make it a very tough job..
What are you trying to accomplish here? During the reinstallation (or upgrading) of a Debian package, replacement of all of the non-conffiles with the latest version is exactly what's supposed to happen. If the file hasn't changed since the last installed version of the package then there's no harm in updating it anyway, and if is has changed, it's supposed to be updated.
If you have specific files which might be modified by the user and should be preserved across upgrades, make then conf files. The package system will prompt the user and ask them if they want to keep the package maintainer's version or the locally modified version.
(But if you're going to make every file a conf file, then you're probably doing something wrong.)
To make a file a conffile, list it in debian/conffiles. But if the file is going to be installed under /etc then you don't need to do this because dh_installdeb will do it for you.
EDIT following additional information in comment:
Suppose you have files test1.sh and test2.sh (among others) in your package. In the Debian world, they are either conffiles are intended to be modified by the end user, or they're not.
conffiles should be relatively few in number and as short as possible, to minimize the burden of having to reconcile changes made by the package maintainer with conflicting changes made by the end user.
If there are things mixed into the code that the end user is likely to want to tune, try to factor them out into a configuration file. If you put that file in /etc, you don't even have to manually designate it as a conffile.
If the end user needs to make a change to a non-conffile, they should use the dpkg-divert protocol to (1) move the original file aside, and (2) edit a copy. Diverted files are respected by package upgrades. The end user who uses dpkg-divert should be aware that things might break after upgrades as a result, because the package maintainer hasn't foreseen that these files would be modified by end users and the locally modified version might be incompatible with a newly upgraded version of a different file. dpkg-divert should be used carefully and sparingly.