The files section of my spec-file looks like this:
%files
%{prefix}/htdocs/
%config %{prefix}/htdocs/share/settings/config.inc.php
Now, since the config file is already included in the %{prefix}/htdocs/ line I get the warning 'File listed twice'.
One way around would be, to list every single file within %{prefix}/htdocs/, except the config file.
But my question is: Is there a better way around this issue, than listing all files?
Unfortunately not. RPM is quite oldschool software, but works fine :-)
But you can use globs too:
%files
%{prefix}/htdocs/*.png
%{prefix}/htdocs/*.html
etc.
This will enable you to include all the rest without some other files you do not want there. That's the way how RPM packagers do it usually.
Related
I use incron for watch a direcory and run a script if a file is added.
In /etc/incron.d/ I have a file with:
/home/pat0/downloads IN_CLOSE_WRITE /var/www/owncloud/scanOC.sh pat0
It's ok when I add a file in /home/pat0/downloads
but, if I create a subdirectory and I add in a file no thing run.
For exemple /home/pat0/downloads/test/myfile.txt is not seen.
How can I watch /home/pat0/download and all its future subdirectories and files?
According to the man page:
... Also, there is the symbol recursive=false. This symbol limits the observation on the specified directory and does not include subdirectories.
This rather implies that in the absence of such a flag incrond will check sub-directories. However my experience is that it does not. Sadly, specifying recursive=true also does not work.
No, I don't think this is possible with incron. Please check with Watcher.
Watcher is a daemon that watches specified files/folders for changes and fires commands in response to those changes. It is similar to incron, however, configuration uses a simpler to read yaml file instead of a plain text file. It's also written in Python, making it easier to hack.
Recursive directory watching in incron is a new feature added in version 0.5.12 (see https://github.com/ar-/incron/blob/master/CHANGELOG):
0.5.12 2015-02-01
added recursive directory watching
added configuration parameters: recursive, dotdirs and loopable
added upstart script
extended manpages and readme
I wonder, if there is a way to do the following:
I have rpmA-v1 installed on the system. It has a lot of config files which user can edit for their purposes. Then, I want to install new version of rpmA, say, rpmA-v2 and before installing it I want to back up those config files, which were edited, not to edit config files one more time.
Is there any way to know which files were edited in such a situation?
If you are talking about config files related to given package, rpm already has pretty robust mechanism for this known as .rpmnew/.rpmsave.
If package is being upgraded, at the discretion of package creator/maintainer there are 2 possible actions that may be taken by rpm:
Old config is preserved intact say at /etc/myprog/config, and new one is installed right next to it as /etc/myprog/config.rpmnew. Presence of *.rpmnew file typically means that old config was NOT edited.
Old config is renamed to /etc/myprog/config.rpmsave, and new one is installed as/etc/myprog/config (replacing old one). New config may be completely fresh (vanilla) or it may incorporate settings inherited from old, .rpmsave'd version. Presence of *.rpmsave files is pretty robust sign that config files were actually edited by rpm.
Typically, after upgrading of one or more packages (or the whole system) it is recommended to search for all .rpmnew/.rpmsave files using command like
find /etc -name "*.rpmsave" -or -name "*.rpmnew"
and carefuly inspect all configs against their .rpmnew/.rpmsave versions (if they are around) to make sure that settings are correct. You can use diff -u to see text diffs or meld for graphical diff/merge.
#mvp has provided a good way to determine changed config files - provided they are marked as such.
If they aren't, you can/should verify the installed package with rpm -V packagename in order to display any changed files.
I am trying to install critlib on my machine (http://equi4.com/critlib/), so that I can create zip files dynamically in Tcl.
The issue is that I have no idea how to install Tcl packages. Is there a certain place you put the folders? Is there a command like yum I can use?
I've skimmed the various Tcl beginners guides and read the sections about packages, but every source always seems to be assuming knowledge I lack.
Yes, there are some directories. To list them, execute tclsh and enter
join $auto_path \n
In each of that directory and its subdir (but not the sub-sub-dir) tcl looks for a file called pkgIndex.tcl.
So if you got an archive, extract it, look where the pkgIndex.tcl is, and copy the directory where this file is in to one of the paths $auto_path. The problem is only to select the appropiate path from the output of step 1.
If you are not sure what the appropiate directory is, I suggest editing the output from the first step into your question.
If you are using vscode and made virtual environment then you can do it as follows
"pipenv install tcl"
I'm able to extract files from a RPM file, but how do I "rebuild" it, for example cpio2rpm?
I have extracted RPM file using following command.
rpm2cpio theFileName.rpm | cpio –idmv
I have to modify the few web application files like *.php, *.html or .js. These files don’t require any source recompilation. So I would like to replaces or change these files with modification without rebuilding rpm. Since, I need to do this for multiple platforms like Redhat Linux and SUSE, and multiple architecture like 32 and 64 bit OS.
I am expecting to do these changes on only on system and without rebuild rpm and there would not be have target system architecture dependency (like i386, 64).
I am not looking like command rpmbuild –rebuild the.src.rpm since, I don’t have source. I need to be rebuild binary .RPM file(not source .rpm)
I want to do this without source and platform or architecture independent and without using spec file if possible.
Any buddy, could you please suggest any solution or any free tools.
Thank you to all whoever spends time to read and reply to my thread.
You can use rpmrebuild to modify an actual rpm file (it doesn't need to be installed).
Most of the examples for this use complicated inline edit commands to modify known files in particular ways, but you can use a normal editor. I used this to fix a shell script in an rpm file that I didn't have the source for. Call the command as
rpmrebuild -ep theFileName.rpm
This puts you in an editor with the spec file for the RPM. The name of the file will be something like ~/.tmp/rpmrebuild.12839/work/spec.2. If you look in, in this example, ~/.tmp/rpmrebuild.12839/work, you will find all of the files used to make the RPM (in my case, the file was in root/usr/sbin within that directory). So, go to another window, cd to that directory, and edit any files you need to change.
When you have finished editing files, go back to the edit window with the spec file, make any changes you need to that file (I didn't have any, since I wasn't adding or deleting files), save the file, and say "y" to the "Do you want to continue" question. It will then build a new RPM file, and tell you where it has put it (in my case, in ~/rpmbuild/RPMS/x86_64/)
You can repackage an installed RPM (including modified files) using rpmrebuild. http://rpmrebuild.sourceforge.net/
Obviously your binaries (if any) would have to be platform/architecture independent to work on all the OS flavors you're hoping for, but it sounds like if they're just web files that shouldn't be a problem.
Principially you can pack everything you want into a RPM file. Just treat what you have as "source" and write a SPEC file which puts the data where the compiled binaries would normally go.
Concerning RPM, I consider "source" "what I have" and "binary" "what I need to run". Not very exact terminology, but it helps working with RPMs.
Your spec file looks like any other spec file, what concerns the parameters etc. But the code part is different:
[...]
%prep
# Here you either have nothing to do or you already unpack the cpio and possibly modify it.
# %build can be omitted
%install
[ "${buildroot}" != "/" ] && [ -d ${buildroot} ] && rm -rf ${buildroot};
# Here you can either unpack the cpio or copy the data unpacked in %prep.
# Be careful to put it into %{buildroot} or $RPM_BUILD_ROOT.
I made a perl script that creates a deb binary package from scratch.
I created the data, control, etc.
But when I run dpkg -i on my deb package it complains that it is unable to files from data.
Example:
unable to create '.dpkg-new'(while processing ''): No such file or directory.
I have downloaded some .deb packages to look at and they do not use the preinst script to create the directory structure.
I am thinking I am doing something wrong, I consider having to create my own directories in preinst but it does not seem right... perhaps I am missing something?
Do I have to create directories where my files from data will be copied in the preinst sh, or should dpkg do it and I am doing something wrong?
I had the same problem in a Ruby script I wrote.
I was generating a list of files to pass to tar when building the data.tar.gz archive. When I ungzip and untared the archive manually it would deflate fine, but dpkg would fail.
It turns out that the list of files must also include each directory to create as well.
Note that when I created data.tar.gz I built it with nearly the same options as dpkg-deb/build.c does in the dpkg-1.15.8.11 source.
execlp(TAR, "tar", "-cf", "-", "--format=gnu", "--null", "-T", "-", "--no-recursion", NULL);
Instead I used
IO.popen("gnutar -czf - --format=gnu -T - --no-recursion", "r+")
In addition to what #Arrowmaster said, check the http://www.debian.org/doc/debian-policy/ for some detailed explanation of the files. After you build the package itself, you can check it with lintian tool to see if there is anything obvious you might have missed.
If any one looks for a solution to the problem:
"Build a deb package from an rpm spec file."
Look here http://www.deepnet.cx/debbuild/
I have made my own perl build script much simple then the mentioned one so I can easily maintain it.
Some useful knowledge gained in the process:
0. the deb is an ar archive that contains 3 files, the order of the files is important.
1. the scripts from control.tar.gz must be made executable.
2. it is good to have a preinstall script to make directories if dirs do not exist.
3. sometimes dpkg decides to unzip your zips (this happened if the zip was the only file in the data.tar.gz) so check for that in an postinstall script.
4. when you tar.gz some files be sure to chmod to the dir that contains the directory structure for your tar.
You should not attempt to manually create a .deb binary package by hand. The Debian New Maintainers' Guide covers how to get started creating a Debian package using the correct tools.
Your hand created package may look correct to you but because it is not installing it is obviously flawed in either a minor way that you have not noticed or in a more serious way that is not visible to you (for example most people don't realize a .deb is actually an ar archive).
There are lots of reasons for this. You really need to run:
dpkg -i -D1110 mydeb.deb
And post the result to have any hope of someone being able to solve the problem.