I'm building an RPM that needs to run a number of scripts to configure it after it's been installed to complete the installation. I have to run the scripts in the %post section because the configuration is dependent upon the type of host. All this is fairly easy and well, but every time I run into a bug with the %post section, I have to rebuild the entire package which takes about 20 minutes. Is there a way to skip recompiling everything and just build a new package with just the changes from %post?
If your spec file doesn't create a random build directory and won't delete that build tree afterwards, the more time consuming compiling can be omitted by make. I.e. Similar to not using the --clean option in rpmbuild.
You can then also use the --short-circuit flag to rpmbuild to skip the first stages in building.
Is the script doing something different when run manually vs. run from the RPM install? You can make a test RPM that has no %post, then manually run the script under test (as root). Do this on every host type that needs to be tested until you think you got it. Then add it as the %post and give it a try.
Related
I'm new to stackoverflow so correct me if I made any mistake in providing the details.
So I'm trying to make a deb file for Apache-Age, and going by the documentation, if we try to install AGE from source then we can simply do it by :
make install
I have setup the basic directory structure by dh_make and have made the control file with proper dependencies, then comes the rule file.
So I went through 2 different extensions of postgreSQL :
postgresql-q3c
Postgis
And tried to replicate the same for apache-age, and tried to build by following commands
dpkg-buildpackage -rfakeroot -b
dpkg-buildpackage -nc -i
the build was giving some errors and warning but a deb file was generated.
The deb file installed properly but age-extension was not installed in PostgreSQL.
It's probably because the age was not building properly from source using make command as specified in the rule file.
Is there any good resource or how to make rule file ?
I tried following this answer, but got stuck here.
I found a PDF but didn't understand the build process.
This might be a naive way but it works for me:
Clone the repo and cd to it
Run the dh_make_pgxs command to make the debian build directory structure.
The you need to make changes to pgversion, control/control.in, changelog, copyright and rule files.
If you are just trying to use the make file to build the package then the rule file can be as simple as:
#!/usr/bin/make -f
%:
dh $#
Then simply run the build command as before.
I've been reading about building RPMs, and the process is quite complex. Is there any program/software that works like this:
Download tar.gz file. Extract to directory
cd into directory
Run
RPM file is output into the directory
Does any such program exist? It seems as if it should. After all, when I run make, make install etc, I don't need to specify spec files, provide locations for where the software has to be installed. So why should I have to do all that for creating RPMs?
I've tried using checkinstall, but I keep getting errors like "Directory not found: /root/rpmbuild/BUILDROOT/hello-2.10-1.x86_64/usr"
So is there an easier way?
No. There is no easier way.
Sometimes upstream provide 'make rpm' target. Sometime checkinstall works. But often you have to create the spec file manually.
BTW that error from checkinstall reveals two things:
you are running that command as root. That is very very unwise.
you should create few build directories. Run command rpmdev-setuptree it will create them for you.
I have downloaded a project which uses sbt as its build system and I want to build it. You'd think it would be as simple as typing "sbt" or something, but no.
I thought I'd add a question for this because it can take literally hours to figure this out on your own. I'm not joking.
tl;dr:
sbt compile
If you want to run it:
sbt run
To see what other targets are available:
sbt tasks
To get some (other) help, but mostly targeted at commands typed from the sbt console (ie, running sbt without parameters):
sbt help
This all assumes sbt version >= 0.10.0. To see what version of sbt is in use, do:
grep sbt.version project/build.properties
If there's no such file, and there's a file with extension ".sbt" on the base directory (not the project directory), then it's >= 0.10.0. Of course, if the grep works, it should tell you the version.
First, you'll want to use sbt-extras, because that automatically downloads and uses the right version of sbt. Trying to use the wrong version of sbt (newer or older than what the project you're trying to build says it requires) won't necessarily work, and may cause strange errors.
Run it:
~/path/to/sbt-extras/sbt
Wait for it to start up and download everything. If you need to use an authenticated proxy, you'll need to edit the script to specify the username and password for the proxy.
Check the version of Scala that sbt thinks it needs to build against (at the end of the output, if everything worked). If this is OK, fine, you don't need to do anything. If it isn't, you can temporarily specify a version explicitly with ++, e.g.:
++2.8.1
(If you want to make this permanent, you can edit the build definition files, but as that involves making a change to files under version control, that might not be what you want to do.)
Now, if you are using an older version of sbt, don't skip the next step! You could get strange errors if you do.
update
Now you can build and test what you've built:
test
If you get an error "Filename too long", this is not an sbt-specific problem, it's a scala problem, which most frequently affects Ubuntu users (technically, for Unbuntu users it's generally related to home directories encrypted with encfs). If you are using Scala >= 2.9, edit the build to use the scalac command-line option that allows you to specify a maximum filename length. Otherwise, if you are on Linux, you can redirect the build to /dev/shm or /tmp, by running these commands in a shell prompt (don't background sbt with CTRL+Z on Unix, because it may appear to stop working properly):
rm -rf target
ln -s /dev/shm target
(you may have to execute these commands in project/build instead or as well.)
Actually, it's probably better, and may even be more secure, to create a subdirectory of /dev/shm or /tmp and use that instead.
The compilation result should appear in target. You might then want to run it, if it's something you can run:
run
If everything looks OK, you can optionally publish the result locally so that the result can then be picked up automatically by other sbt builds:
publish-local
I don't think I could explain it better that the Getting Started Guide could. Please read the first 6 parts of it, which shouldn't too long time, to get it up and running.
Let's say I've created a directory using module-starter, and written several additional modules and tests since.
make test would then run all tests in t/ on all modules in lib/, however make dist will only pack files mentioned in MANIFEST into tar.gz.
So I got burnt recently by running make test && make dist and still getting a broken package.
My question is: am I missing something, or this can be reported as a minor bug in MakeMaker? (Which Makefile.PL seems to rely upon).
You can use make disttest which will create a distribution directory from the MANIFEST (equivalent to make distdir) and run make test in that. This guarantees you're running against the same files as will be shipped.
I also rebuild my MANIFEST as part of making a release, which requires keeping your MANIFEST.SKIP up to date.
All in all, my basic release script is:
perl Makefile.PL
make manifest
make disttest
make dist
Run make distcheck before you release your package. This will warn you about anything potentially missing from your MANIFEST.
Some modules generate files during the build process (including under lib/), so files missing in the MANIFEST shouldn't necessarily cause make dist to fail.
I'm using Solaris 10, ksh. Whenever I do a ./configure, I get the error "ksh: ./configure: not found"
When I do a "where configure", nothing is found.
How do I "install configure"?
./configure means that you want to run an executable called configure in your current directory (signified by a .). I'm guessing you're trying to build and install from source, and the directions say to do the standard ./configure; make; make install. You should do that from the top-level directory of the source you downloaded and unpacked:
$ cd /path/to/source
$ ./configure
$ make
$ make install
"./configure" means "run the program configure from the current directory". That is, you need to cd to the directory that configure lives in before attempting to run it like that.
As for where configure might be found, it's usually at the root of whatever source package you're trying to build.
I'm not a Solaris guy, but the configure script should be within your current directory before you execute it. I am assuming you're trying to build something. If it's a project of your own, take a look at GNU autoconf. (I have no idea if this a part of Solaris or not.) It's part of M4.
If it's a project that you downloaded, untar/unzip/unpack it and then cd to its directory before running the configure script.
I had to run a command for another directory; and then that popped everything up :)
In case someone else comes across this specific issue, I'm trying to install the Perl-Php plugin on a Solaris machine. Initially, there is no configure file; instead you have to find where your "phpize" is located -- for me it was /opt/webstack/php/5.2/phpize, run it while you are still in the "perl-php-plugin" folder, and then configure will appear.
Then you can ./configure :)
Thanks to everyone who responded.