I have set my minimum stability to be dev but I'd like one module to avoid installing the dev-master release. I'd like to put in, for example, >=1.3 and not get dev-master. Is this possible?
After some more research and changing how I searched I found that Composer has a prefer-stable option that can be used to achieve this
Related
I have built a RPM-package for Centos 6.6 that is installed on a machine of our customer.
This package contains our own software, customized for the specific use case, but also uses the open-source package HAProxy.
HAProxy (RPM-version 1.5.4-2.el6_7.1) comes with a default-configuration in /etc/haproxy/haproxy.conf and it cannot be customized without changing this file.
But I want the configuration to be part my generated package. RPM throws an error if the /etc/haproxy/haproxy.conf file is in my package, because it is also part of the haproxy-package.
I have worked around this problem by providing a custom upstart-script which starts HAProxy with a different config file, but this does not seem to be the right way to do this.
Is there a preferred way to handle such customizations?
In cases like this, I've created an RPM which installs configuration files into a different subdirectory, and in its %post and %preun scriptlets modifies the uncooperative package's config-files:
when installing, I renamed the original config-files, and made symbolic links from those pathnames to the overwriting config-files, and
when uninstalling, the package removed the symbolic links and restored the original package's files.
Doing it that way of course meant that my config-RPM was dependent on the original RPM. A little awkward to describe, but it works.
In followup, the issue of updating was mentioned. Updating an RPM requires special handling to avoid uninstalling things. The rpm program passes a parameter $1 which you can test in the %pre and %preun scriptlets to notice that this is an upgrade and that there is no need to save the original config-files (or restore them). The rest of the scriptlet would be the same, by copying the new versions of your config-files over the others.
Further reading:
Defining installation scripts (shows the use of `$1)
RPM upgrade uninstalls the RPM
Your approach is correct. On EL6 and sysv there is no other choice than creating custom haproxy package or custom haproxy service or create script which customer runs after installation. I see creating another service as best option.
Note that on EL7 with SystemD you have much better option as you can use Drop-In feature of SystemD. For more information see:
https://coreos.com/os/docs/latest/using-systemd-drop-in-units.html
https://wiki.archlinux.org/index.php/systemd#Drop-in_snippets
https://wiki.archlinux.org/index.php/Systemd/User#Service_example
The usual way this is done is to have a drop-in configuration directory, e.g. /etc/httpd/conf.d/, where your package would drop its configuration, and you would tell the other daemon, e.g. httpd, to do a graceful restart in your %post/%postun.
I don't know anything about HAProxy, but a quick search implies that they do not support this configuration directory concept that has been around for many years. A few people have hacked it in, but unless it is out-of-the-box, you will run into your original problem again.
On VirtualBox VM OpenBSD:
I was trying to build apr 1.5.1 in my attempt to build an apache 2.4 server WITHOUT packages( ie. from source ) and when I ran make test, testlock failed with:
testlock : -Line 300: Timer returned too late FAILED 1 of 4
...
*** Error 1 in test (Makefile:186 'check')
*** Error 1 in /a/b/c/d/e/f (Makefile:127 'check')
I have no idea what to do with it. What is the course of action for something like this?
You may want to try using a slightly older version of apr; perhaps one from an OpenBSD packages site (somewhere like this OpenBSD Packages site?)
Note: any downloads and installations that you choose to make from sites like these are your decision. Please make sure to read related documentation for compatibility information, too, before making a decision about installing software in your environment!
Also, your version of OpenBSD may make a difference for what package site would be best to use... the OpenBSD packages site above is just an example of what these sites may look like.
For future reference, you can find more information about these sort of packages in the OpenBSD packages and ports documentation.
I am packaging several parts of my company icinga installation as RPMs, to be used in the transaction from a central monitoring solution to a distributed one.
Along the way I have packaged the nagios plugins folder easily and I have discovered that newer versions of rpmbuild calculate requirements automatically using ldd.
Now my package has a huge list of unmet dependencies, mostly perl modules. Some of these requirements are cryptic or equivocal: I can't find anything about them in google or the repositories:
icinga.plugins-1.0-1.i686 has missing requires of perl(a)
icinga.plugins-1.0-1.i686 has missing requires of perl(snmp) #which module is this???
...
I guess I can find out most of them, but perl(a).
Any help would be appreciated.
You can disable auto requirements at all, or manipulate the auto requirements mechanism to ignore specific requirements. Look here:
http://www.redhat.com/archives/rhl-list/2005-August/msg00461.html
I'm trying to use the same CentOS instance to get me to build packages for both versions 5 and 6. Until now everything was working OK, but I think an update in the building instance (6) now includes some dependencies that seems they're not available in version 5:
error: Failed dependencies:
rpmlib(FileDigests) <= 4.6.0-1 is needed by pulse-13.1.0-181013.noarch
rpmlib(PayloadIsXz) <= 5.2-1 is needed by pulse-13.1.0-181013.noarch
My question: is there any way of doing this? Is this even suppose to work i.e. building RPM for different target versions?
There are two ways whose performance is better than normal VM:
Make CentOS 5 or 6 chroot environment and build RPM inside it.
Configure LXC and builde RPM inside it, see also http://wiki.centos.org/HowTos/LXC-on-CentOS6 and http://whistl.com/index.php/blog/2011/08/28/linux-containers-under-centos-6
you can try crosstool-ng. OSDev Wiki page has a lot of information about cross compilation.
Simple enough question. When I run yum update on a CentOS box, do I need to manually restart mysqld, httpd, ... and so on if they have been updated, or do they get restarted automatically?
Does anyone know where to find a source to back this up?
It depends on what's in the %post scripts of the .spec file for each package.
Generally, they don't always do so as I recall.
httpd at least does; see http://pkgs.fedoraproject.org/cgit/httpd.git/tree/httpd.spec?id=ea6aac8abd84867119fd84a057daceb75e160bc1 and take a look at the %posttrans scriptlet.
Looks like that was added in Fedora 10: http://pkgs.fedoraproject.org/cgit/httpd.git/tree/httpd.spec?h=f10
because of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=491567