I'd like to specify a different build and deployment path for files, how can I specify this? I have a directory of files on my build box at pathA,and would like to install these on pathB.
%files subpackagetest
%defattr(0644,%{_package_owner},%{_package_owner},0755)
/source/path/on/build/box /deployment/path
Thanks for any ideas
Look at the %install section of the spec file. Something like below should do the trick.
%install
mkdir -p %{buildroot}/deployment/path
cp -R /source/path/on/build/box %{buildroot}/deployment/path
%file subpackagetest
%defattr(0644,%{_package_owner},%{_package_owner},0755)
/deployment/path
See http://www.logiqwest.com/TechnicalPapers/rpmScriptInstall.html for an example.
Related
Why does %files needed and why it cannot be created automatically by listing $RPM_BUILD_ROOT directory contents?
For example, in that spec file i have to use some modifications in it in script, that build an RPM package for me. I have to cd into ~/RPM/SOURCES, then find . in it and echo each line into .spec file to setup %files section. It can be done automatically by the tool using the same techniuque i do in the background but from $RPM_BUILD_ROOT directory instead?
%install
mkdir -p $RPM_BUILD_ROOT/opt/MyCompany/MyProduct/
cp -rf -- ~/RPM/SOURCES/* $RPM_BUILD_ROOT/opt/MyCompany/MyProduct/
%files
/opt/MyCompany/MyProduct/file_1
/opt/MyCompany/MyProduct/file_2
/opt/MyCompany/MyProduct/file_3
... - a lot of lines here
/opt/MyCompany/MyProduct/file_100000
UPD:
Yes it is possible to use all copied files automatically (Doc http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html)
In my case %files can be rewritten as that
%files
/opt/MyCompany/MyProduct/*
It will take files from $RPM_BUILD_ROOT/opt/MyCompany/MyProduct, so to use star we need to omit build root which is $RPM_BUILD_ROOT or %{buildroot} (Which is default path where rpm searches for files IIUC)
Why does %files needed and why it cannot be created automatically by listing
$RPM_BUILD_ROOT directory contents?
It is common that one spec file build creates multiple (sub)packages - then also
multiple %files sections are needed.
Even though there exist some automatic %files
section
generators,
nb there's the
%files -f option,
in general it isn't possible to split the files automatically.
Worth saying that most of the package maintainers don't maintain the software
source code, but just package the "upstream" releases. If the %files sections
are rather manually maintained (in contrast with the wildcard patterns), the
package maintainer has everything a bit more under control because he is
notified about the changes in the software installation layout (e.g. when a new
file appears in /usr/bin with a new release, rpmbuild starts complaining that
there's a new "unpackaged" file, see below).
It can be done automatically by the tool using the same techniuque i do in the
background but from $RPM_BUILD_ROOT directory instead?
You don't even have to run find manually. As long as %install creates the
files in $RPM_BUILD_ROOT, if you don't mention them in %files - you get reports
like those:
$ rpmbuild -bb *.spec
...
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/user/rpmbuild/BUILDROOT/test-1-1.x86_64
error: Installed (but unpackaged) file(s) found:
/usr/bin/not-packaged
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/bin/not-packaged
Is it possible to have a separate %install section for a subpackage in a spec file?
For example, files can be specified for the main package as
%files
and for the subpackage like this:
%files mysubpackage
however, I have only seen one
%install
section, and I get an error if I do
%install mysubpackage
no, you cannot have, and you don't need a separate %install section.
Let's suppose a typical example: you compile a program and want to create two packages; library.rpm and library-devel.rpm (with the headers). Then you'll have a spec file something like this:
Name: library
# probably some other fields...
%description
describre library
%package devel
Summary: headers for library
%description devel
describe library-devel package
%prep
# some common prep code for both packages; eg
%setup -q
%build
make (or whatever to build your program)
%install
# install files for both rpm packages; library AND headers
mkdir -p ${RPM_BUILD_ROOT}/%_libdir/
mkdir -p ${RPM_BUILD_ROOT}/usr/include/
cp library.so* ${RPM_BUILD_ROOT}/%_libdir/
cp include/*.h* ${RPM_BUILD_ROOT}/usr/include/
%files
%defattr(-,root,root)
%_libdir/*.so.*
%files devel
%defattr(-,root,root)
%_libdir/*.so # yes; if you use version numbers; the versioned .so go in the normal package; the one without version number in the devel package
/usr/include/*
further reading: RPM packaging guide
I am having trouble symlinking dotfiles. I have a folder in my home directory ~/dotfiles which I have synced to a github repo. I am trying to take my .vimrc file in ~/dotfiles/.vimrc and create a symbolic link to put it at ~/.vimrc. To do this I type in
ln -s ~/dotfiles/.vimrc ~/.vimrc
But when I run that it says
ln: /Users/me/.vimrc: File exists
What am I doing wrong?
That error message means that you already have a file at ~/.vimrc, which ln is refusing to overwrite. Either delete the ~/.vimrc and run ln again or let ln delete it for you by passing the -f option:
ln -s -f ~/dotfiles/.vimrc ~/.vimrc
There is a better solution for managing dotfiles without using symlinks or any other tool, just a git repo initialized with --bare.
A bare repository is special in a way that they omit working directory, so you can create your repo anywhere and set the --work-tree=$HOME then you don't need to do any work to maintain it.
Approach
first thing to do is, create a bare repo
git init --bare $HOME/.dotfiles
To use this bare repo, you need to specify --git-dir=$HOME/.dotfiles/ and --work-tree=$HOME, better is to create an alias
alias dotfiles='/usr/bin/git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME
At this point, all your configuration files are being tracked, and you can easily use the newly registered dotfiles command to manage the repository, ex :-
# to check the status of the tracked and untracked files
dotfiles status
# to add a file
dotfiles commit .tmux.conf -m ".tmux.conf added"
# push new files or changes to the github
dotfiles push origin main
I also use this way to sync and store my dotfiles, see my dotfiles repository and can read at Storing dotfiles with Git where I wrote about managing for multiple devices.
How to symlink all dotfiles in a directory recursively
Have a dotfiles directory that is structured as to how they should be structured at $HOME
dotfiles_home=~/dotfiles/home # for example
cp -rsf "$dotfiles_home"/. ~
-r: Recursive, create the necessary directory for each file
-s: Create symlinks instead of copying
-f: Overwrite existing files (previously created symlinks, default .bashrc, etc)
/.: Make sure cp "copy" the contents of home instead of the home directory itself.
Tips
Just like ln, if you want no headache or drama, use an absolute path for the first argument like the example above.
Note
This only works with GNU cp (preinstalled in Ubuntu), not POSIX cp. Check your man cp, you can install GNU coreutils if needed.
Thanks
To this and this.
I'm trying to move .zshrc to a folder where I keep this kind of files synced with Github.
But now whenever I start a zsh session it doesn't use that config file.
Assuming I changed the file to ~/.dotfiles how can I add ~/.dotfiles/.zshrc to the PATH(?!) to make zsh start with that config?
Doing source ~./dotfiles/.zshrc only works for that session. Doesn't work anymore if I close the terminal.
You can symlink:
ln -s /path/to/original /path/to/symlink
For the zshrc you can do something like:
ln -s ~/.dotiles/.zshrc ~/.zshrc
One alternative to a symlink is to put this in ~/.zshenv:
ZDOTDIR=~/.dotfiles
If you want .zshenv in ~/.dotfiles as well, you can look into setting ZDOTDIR in one of the global configuration files (/etc/zshenv is a good choice).
Alternatively, you can do what I do and use GNU Stow. I've got my dotfiles in a repository, one subdirectory per category, like so:
dotfilerepo/zsh/.zshrc
dotfilerepo/zsh/.zlogin
dotfilerepo/git/.gitconfig
dotfilerepo/vim/.vimrc
then I can cd into repo and do stow zsh and it'll create a symlink from ~/.zshrc to repo/zsh/.zshrc, another from zsh/.zlogin to ~/.zlogin. stow vim to create symlinks from the vim subdirectory to ~, etc.
I've got a script, install-linkfarm, that does all the stow commands so when I move onto a new machine, I clone my repo, cd to it and run install-linkfarm and am good to go.
You can put this in ~/.zshrc, even as its entire contents:
if [ -r ~/.dotfiles/.zshrc ]; then
source ~/.dotfiles/.zshrc
fi
Please use the export command mentioned below to solve your problem.
export ZDOTDIR=$HOME/.dotfiles
In Linux, you can check if your zsh is loading /etc/zsh/zshrc, and edit it.
If that's the case, redirect this to your custom script by adding:
sh $HOME/.dotfiles/zshrc
Here is an interesting hack that doesn't require you to use sym-links.
In your .xsession, (or .*wmrc) have the following:
xterm -e 'zsh -c ". ~/.dotfiles/.zshrc; zsh"'.
instead of just:
xterm
Make sure to put the -e at the end after all of your other xterm options.
If my .zshrc file is ~/.dotfiles/zsh/.zshrc, how can I create a symlink so that the file appears as ~/.zshrc?
The cd step in Alexej's answer isn't needed as you can call ln -s target destination explicitly.
ln -s ~/.dotfiles/zsh/.zshrc ~/.zshrc
run:
cd ~/ ; ln -s ~/.dotfiles/zsh/.zshrc
for me, when using relative path for symlink, it can show error: ~/.zshrc: No such file or directory error as #astephen2. You should change to absolute path then it working fine
You don't actually need a symlink. Add the following to ~/.zshenv:
ZDOTDIR=~/.dotfiles/zsh
zsh sources ~/.zshenv before any other files, and will use the value of $ZDOTDIR as the location for local configuration files in lieu of your home directory.
On MacOS, you can't use ~ in a symlink where the directory is quoted. You need to use full paths. I'd recommend running ln -s "$HOME/.dotfiles/zsh/.zshrc" "$HOME/.zshrc" Alternatively, you can forget the quotes, and use ~ in place of $HOME, however if there are any spaces (or variables with spaces) you'll probably run into problems.