Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
My development server (CentOS 5) is running Subversion 1.4.2, and I wish to upgrade it to 1.5. I have read in various blogs and documents scattered around the web that this may be done by using RPMForge. I have followed the instructions found on CentOS Wiki, including installing yum-priorities and setting my priorities as indicated (1 and 2 for core repo sources, and 20 for RPMForge).
However, when I attempt to run:
$ yum info subversion
the version number given to me is still 1.4.2, with a status of Installed. My other option at this point is compiling from source, but I would like to find a package-managed solution for ease of future upgrades.
Any thoughts?
What you are trying to do is to replace a "core" package (one which is
contained in the CentOS repository) with a newer package from a "3rd
party" repository (RPMForge), which is what the priorities plugin is
designed to prevent.
The RPMForge repository contains both additional packages not found in
CentOS, as well as newer versions of core packages. Unfortunately, yum
is pretty stupid and will always update a package to the latest version
it can find in any repository. So running "yum update" with RPMforge
enabled will update half of your system with the latest (bleeding edge,
possibly unstable and less well supported) packages from RPMForge.
Therefore, the recommended way to use repos like RPMForge is to use them
only together with a yum plugin like "priorites", which prevents
packages from "high" priority repos to overwrite those from "low"
priority repos (the name of the "priority" parameter is very
misleading). This way you can savely install additional packages (that
are not in core) from RPMForge, which is what most people want.
Now to your original question ...
If you want to replace a core package, things get a little tricky.
Basically, you have two options:
Uninstall the priority plugin, and disable the RPMForge repository by
default (set enabled = 0 in /etc/yum.repos.d/rpmforge.repo). You can
then selectively enable it on the command line:
yum --enablerepo=rpmforge install subversion
will install the latest subversion and dependencies from RPMForge.
The problem with this approach is that if there is an update to the
subversion package in RPMForge, you will not see it when the repo is
disabled. To keep subversion up to date, you have to remember to run
yum --enablerepo=rpmforge update subversion
from time to time.
The second possibility is to use the priorites plugin, but manually
"mask" the core subversion package (add exclude=subversion to the
[base] and [update] sections in /etc/yum.repos.d/CentOS-Base.repo).
Now yum will behave as if there is no package named "subversion" in
the core repository and happily install the latest version from
RPMForge. Plus, you will always get the latest subversion updates
when running yum update.
1.- if you are using yum-priorities disable this in the file /etc/yum/pluginconf.d/priorities.conf
2.- check the version of subversion
$ rpm -qa|grep subversion
subversion-1.4.2-4.el5_3.1
subversion-1.4.2-4.el5_3.1
3.- search the last version of the subversion from rpmforge repository
$ yum --enablerepo=rpmforge check-update subversion
subversion.x86_64 1.6.6-0.1.el5.rf rpmforge
4.- now proced to upgrade subversion with rpmforge repository
$ yum shell
>erase mod_dav_svn-1.4.2-4.el5_3.1
>erase subversion-1.4.2-4.el5_3.1
>install mod_dav_svn-1.6.6-0.1.el5.rf
>install subversion-1.6.6-0.1.el5.rf.x86_64
>run
that's all it works for me im running centos 5.4
Thanks Matt - we also have the only distro of SVN 1.7 on SVN.
You may also want to try uberSVN.
If you install RPMForge's repos, you should then be able to get a newer package - this isn't working for you?
You should see rpmforge.list in /etc/apt/sources.list.d with a line like:
repomd http://apt.sw.be redhat/el$(VERSION)/en/$(ARCH)/dag
I just tested on a clean CentOS 5 install, and yum check-update shows
subversion.i386 1.5.2-0.1.el5.rf rpmforge
subversion-perl.i386 1.5.2-0.1.el5.rf rpmforge
So check your sources list and run check-update again.
Edit: Whoops, lost part of my answer. Added it back above.
I'm not overly concerned about the other outdated packages at the moment, but as you can see there is no Subversion update available.
Nor any packages from rpmforge. It's your priority settings. Try disabling yum-priorities (change enabled=1 to enabled=0 in /etc/yum/pluginconf.d/priorities.conf) - then it should work.
So I guess the next question is why the priority is screwing it up.... I'm not sure on this, though.
Edit: See 8jean's answer for more about priorities.
its up to v 1.4.6 in Dag's repository.
You can try the one from Fedora's repo or have a bit of patience for the main repositories to upgrade it.
Making it from source is easy, read the INSTALL file when you download the source package, bear in mind CentOS may have moved where the files get installed. (Use "rpm -ql subversion" to see where the old files were installed to).
When v1.5.0 gets released to the repository, you can delete your built version and install using yum as before.
RPMForge is already in /etc/yum.repos.d/ as rpmforge.repo, and the contents are:
# Name: RPMforge RPM Repository for Red Hat Enterprise 5 - dag
# URL: http://rpmforge.net/
[rpmforge]
name = Red Hat Enterprise $releasever - RPMforge.net - dag
#baseurl = http://apt.sw.be/redhat/el5/en/$basearch/dag
mirrorlist = http://apt.sw.be/redhat/el5/en/mirrors-rpmforge
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge
enabled = 1
protect = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1
priority=20
I have that exact line in in /etc/apt/sources.list.d/rpmforge.list .
When I run check-update, I get:
Loading "priorities" plugin
Loading "fastestmirror" plugin
Loading mirror speeds from cached hostfile
* epel: mirror.unl.edu
* rpmforge: fr2.rpmfind.net
* base: mirrors.portafixe.com
* updates: mirrors.portafixe.com
* addons: mirrors.portafixe.com
* extras: mirrors.portafixe.com
2202 packages excluded due to repository priority protections
bzip2.i386 1.0.3-4.el5_2 updates
bzip2-devel.i386 1.0.3-4.el5_2 updates
bzip2-libs.i386 1.0.3-4.el5_2 updates
libxml2.i386 2.6.26-2.1.2.6 updates
libxml2-devel.i386 2.6.26-2.1.2.6 updates
libxml2-python.i386 2.6.26-2.1.2.6 updates
perl.i386 4:5.8.8-15.el5_2.1 updates
sos.noarch 1.7-9.2.el5_2.2 updates
tzdata.noarch 2008e-1.el5 updates
I'm not overly concerned about the other outdated packages at the moment, but as you can see there is no Subversion update available.
All you need to do is get this script. worked perfectly for me on CentOS 5.3
http://wandisco.com/subversion/os/downloads
No, i don't work there or have any affiliation what-so-ever ... just found it and figured I would let you guys knows.
Good luck.
Related
Good afternoon,
I am currently building an RPM that has some requirements I have not found answers to on the web. I have narrowed this down to a single question.
Normally when I run an install from command line, one of the steps has me run the following command yum groupinstall "Compatibility libraries" which installs 32-bit compatibility libraries on my 64-bit desktop. I am wondering if there is a way to accomplish this in the Requires: field of my RPM-spec file, as I have only found a way to require very specific RPM's for dependencies?
I could always add in the 10-15 individual packages that get installed with yum groupinstall "Compatibility Libraries", but I was hoping there was a better option.
Description of RPM:
My RPM is very basic in nature. It will untar multiple tar files into various locations, overwrite files throughout the main install directory, install compatibility libraries, and then proceed to startup a service.
If anyone needs more information to what I am trying to accomplish please let me know. Thank you.
You can only require specific packages, not groups, in your Requires: lines. You should absolutely not run yum in your %post script, because then (a) you are then hiding your dependencies, and nobody likes to see things get installed that they didn't expect, and (b) you will probably end up getting stuck because yum in %post would need to wait for the existing yum process to exit.
For library Requires:, the rpm build process will generally figure things out for you. You still need to manually specify the appropriate BuildRequires: dependencies, which are things that are required to build the package.
If you want to update your question with more details (e.g., a link to the spec file and a description of what you're trying to do, if it's not obvious from the spec), maybe we can come up with better solutions.
I want to host an apt-get repository.
How do I package my application, and how do I host it in a repository for use?
The application relies on Java, MySQL, upstart and is configured to run on boot as an upstart service.
The answer should also include, how to host the package on a repository.
Ref:
How do I package a Java program for Ubuntu?
How do I package Mono applications for Debian/Ubuntu
Packaging for Ubuntu - Web Application
Good question, maybe a personal ppa is what you are looking for. After you finish you will have to do a $ sudo add-apt-repository ppa:myApp/ppa. Then you can apt-get install it.
To package your application you will need to do this in your apps directory
myappFolder$ dh_make -p myApp_1.0 --createorig
To create a original tar of your app. This will also create a Debian folder with a control file, a rules file, changelog... Change the values in these files to fit how your package should be. Specifically the control file. You will have a Depends: field where you can write in packages your application relies on such as Java and MySQL, make sure to have the same names as Ubuntu repository for these things.
goodLink https://www.debian.org/doc/manuals/maint-guide/dreq.en.html
Check out chapter 5 the install file and then building the package in chapter 6. I use dpkg-buildpackage usually. debuild -us -uc is good too look up too.
Then create an account on Ubuntu launchpad.
https://login.launchpad.net/+new_account
Sign the Ubuntu code of conduct:
https://launchpad.net/codeofconduct (take away the extra h, no reputation for more links)
Activate a PPA:
https://launchpad.net/people/+me/ (extra h)
Then follow this guide to upload the package to your ppa:
https://help.launchpad.net/Packaging/PPA/Uploading (extra h)
I got these links from a great answer on ask.ubuntu. It's also got a more lengthy answer on creating a deb package.
https://askubuntu.com/questions/71510/how-do-i-create-a-ppa
There are many packages that are listed on the Debian site as being included in the repositories and fully supported by Debian, but when I try 'apt-get install' I am told: E: Unable to locate package. They also do not exist in synaptic.
Specifically, I am trying to install remmina (which should be simple), but has consumed several hours from my day. There seems to be no info on this. As I installed Debian with only DVD 1, I am assuming I need to download the references to most of the packages somewhere, but cannot find where or how to go.
I wanted to post a view of my sources list, but there are all kinds of formatting rules that I must follow, and then I am told I need x reputation points to post links (many addresses in sources.list). Basically I have main, contirb, and non-free enabled.
Thanks
If a package is available on repository, then it should be available to you too.
Check name of the package with apt-cache search <packagename> or aptitude search <packagename> ( I do prefer aptitude to search packages ).
Double check if the desired component is enabled at your sources.list file and under sources.list.d/. Many people forget to enable the famous contrib and non-free components. Check which component is related to your package and update your sources.list.
I found these .deb files:
http://ftp.us.debian.org/debian/pool/main/r/remmina/remmina_1.0.0-4+deb7u1_amd64.deb
http://ftp.us.debian.org/debian/pool/main/r/remmina/remmina-common_1.0.0-4+deb7u1_all.deb
As you can see, according to sources.list documentation these files are under the main component.
I'm working on a Scientific Linux box and am trying to install Maven using the yum command. Scientific Linux for those of you who do not know is based off of Red Hat Linux Enterprise Edition 6.
I'd prefer to install Maven in a way that lent itself to easy updating, that is why I have shied away from simply going to the Apache Maven site and getting the files I need.
Simply running yum with root privileges was not enough. I used yum search maven which returned "JPackage Utilities", which I tried to install only to get:
Package jpackage-utils-1.7.5-3.12.el6.noarch already installed and latest version
I was assuming that something like creating a new repo file something like /etc/yum.repos.d/maven.repo would do the trick.
I found a site suggesting that I point my maven.repo file to the URL http://www.jpackage.org/jpackage50.repo, however this seems to be a fix for an older version of Linux as it did not solve my problem
As always thanks in advance for any help or suggestions!
The distro agnostic generic repo is what you want. As root, add a couple of the jpackage-generic repos to yum (two snippets below). Then perform a yum update and finally yum install maven2.
cat > /etc/yum.repos.d/jpackage-generic-free.repo << EOF
[jpackage-generic-free]
name=JPackage generic free
baseurl=http://mirrors.dotsrc.org/jpackage/6.0/generic/free/
enabled=1
gpgcheck=1
gpgkey=http://www.jpackage.org/jpackage.asc
EOF
cat > /etc/yum.repos.d/jpackage-generic-devel.repo << EOF
[jpackage-generic-devel]
name=JPackage Generic Developer
baseurl=http://mirrors.dotsrc.org/jpackage/6.0/generic/devel/
enabled=1
gpgcheck=1
gpgkey=http://www.jpackage.org/jpackage.asc
EOF
I had all kinds of conflicts trying to use the JPackage repo with Scientific Linux 6.2, but I had much better luck with dchen's repo from the "Fedora People" unofficial repositories. The repo config I used is:
# Note: Replaced $releasever with 6Server since SL's "6.2" doesn't work
[epel-apache-maven]
name=maven from apache foundation.
baseurl=http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-6Server/$basearch/
enabled=1
skip_if_unavailable=1
gpgcheck=0
[epel-apache-maven-source]
name=maven from apache foundation. - Source
baseurl=http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-6Server/SRPMS
enabled=0
skip_if_unavailable=1
gpgcheck=0
The package itself is called apache-maven and installs maven 3.0.3.
This is more updated way:
curl http://www.jpackage.org/jpackage50.repo > /etc/yum.repos.d/jpackage.repo
yum update
yum install maven2
Thanks Andy for his answer (on Jun 10, 2011). It gave me some hints. However, when I followed it, I got a lot of dependencies issues, including problems like these
ERROR with rpm_check_debug vs depsolve:
rpmlib(FileDigests) is needed by plexus-container-default-1.0-0.a9s1.2.jpp6.noarch
rpmlib(FileDigests) is needed by aspectj-1.5.4-1.jpp6.noarch
rpmlib(FileDigests) is needed by rhino-1.7-1.r2.8.jpp6.noarch
rpmlib(FileDigests) is needed by saxon9-dom-B.9.0.0.8-2.jpp6.noarch
rpmlib(FileDigests) is needed by easymock2-2.5.2-2.jpp6.noarch
rpmlib(FileDigests) is needed by saxon9-B.9.0.0.8-2.jpp6.noarch
rpmlib(FileDigests) is needed by saxon9-xpath-B.9.0.0.8-2.jpp6.noarch
rpmlib(FileDigests) is needed by xmlbeans-2.4.0-3.jpp6.noarch
rpmlib(FileDigests) is needed by jtidy-7.0-0.V04aug2000r7_dev.2.jpp6.noarch
rpmlib(FileDigests) is needed by lucene-2.4.1-5.jpp6.noarch
rpmlib(FileDigests) is needed by aqute-bndlib-0.0.363-1.jpp6.noarch
Finally I realized the JPackage website actually has good and updated instruction. So I following these two pages and could finally installed maven2 on my machine.
Jpackage.org: Installation
Jpackage.org: Using a Repository -- Yum
I'm looking into trying to find an easy way to manage packages compiled from source so that when it comes time to upgrade, I'm not in a huge mess trying to uninstall/install the new package.
I found a utility called CheckInstall, but it seems to be quite old, and I was wondering if this a reliable solution before I begin using it?
http://www.asic-linux.com.mx/~izto/checkinstall/
Also would simply likely to know any other methods/utilities that you use to handle these installations from source?
Whatever you do, make sure that you eventually go through your distribution's package management system (e.g. rpm for Fedora/Mandriva/RH/SuSE, dpkg for Debian/Ubuntu etc). Otherwise your package manager will not know anything about the packages you installed by hand and you will have unsatisfied dependencies at best, or the mother of all messes at worst.
If you don't have a package manager, then get one and stick with it!
I would suggest that you learn to make your own packages. You can start by having a look at the source packages of your distribution. In fact, if all you want to do is upgrade to version 1.2.3 of MyPackage, your distribution's source package for 1.2.2 can usually be adapted with a simple version change (unless there are patches, but that's another story...).
Unless you want distribution-quality packages (e.g. split library/application/debugging packages, multiple-architecture support etc) it is usually easy to convert your typical configure & make & make install scenario into a proper source package. If you can convince your package to install into a directory rather than /, you are usually done.
As for checkinstall, I have used it in the past, and it worked for a couple of simple packages, but I did not like the fact that it actually let the package install itself onto my system before creating the rpm/deb package. It just tracked which files got installed so that it would package them, which did not protect against unwelcome changes. Oh, and it needed root prilileges to work, which is another main sticking point for me. And lets not go into what happens with statically linked core utilities...
Most tools of the kind seem to work that way, so I simply learnt to build my own packages The Right Way (TM) and let checkinstall and friends mess around elsewhere. If you are still interested, however, there is a list of similar programs here:
http://www.dwheeler.com/essays/automating-destdir.html
PS: BTW checkinstall was updated at the end of 2009, which probably means that it's still adequately current.
EDIT:
In my opinion, the easiest way to perform an upgrade to the latest version of a package if it is not readily available in a repository is to alter the source package of the latest version in your distribution. E.g. for Centos the source packages for the latest version are here:
http://mirror.centos.org/centos/5.5/os/SRPMS/
http://mirror.centos.org/centos/5.5/updates/SRPMS/
...
If you want to upgrade e.g. php, you get the latest SRPM for your distrbution e.g. php-5.1.6-27.el5.src.rpm. Then you do:
rpm -hiv php-5.1.6-27.el5.src.rpm
which installs the source package (just the sources - it does not compile anything). Then you go to the rpm build directory (on my mandriva system its /usr/src/rpm), you copy the latest php source tarball to the SOURCES subdirectory and you make sure it's compressed in the same way as the tarball that just got installed there. Afterwards you edit the php.spec file in the SPECS directory to change the package version and build the binary package with something like:
rpmbuild -ba php.spec
In many cases that's all it will take for a new package. In others things might get a bit more complicated - if there are patches or if there are some major changes in the package you might have to do more.
I suggest you read up on the rpm and rpmbuild commands (their manpages are quite good, in a bit extensive) and check up the documentation on writing spec files. Even if you decide to rely on official backport repositories, it is useful to know how to build your own packages. See also:
http://www.rpm.org/wiki/Docs
EDIT 2:
If you are already installing packages from source, using rpm will actually simplify the building process in the long term, apart from maintaining the integrity of your system. The reason for this is that you won't have to remember the quirks of each package on your own ("oooh, right, now I remember, foo needs me to add -lbar to its CFLAGS"), as the build process will be in the .spec file, which you could imagine as a somewhat structured build script.
As far as upgrading goes, if you already have a .spec file for a previous version of the package, there are two main issues that you may encounter, but both exist whether you use rpm to build your package or not:
A patch that was applied to the previous version by the distribution does not apply any more. In many cases the patch has already been applied to the upstream package, so you can simply drop it. In others you may have to edit it - or I suppose if you deem it unimportant you can drop it too.
The package changed in some major way which affected e.g. the layout of the files it installs. You do read the release notes notes for each new version, don't you?
Other than these two issues, upgrading often boils down to just changing a version number in the spec file and running rpmbuild - even easier than installing from a tarball.
I would suggest that you have a look at the tutorials or at the source package for some simple piece of software such as:
http://mirror.centos.org/centos/5.5/os/SRPMS/ipv6calc-0.61-1.src.rpm
http://mirror.centos.org/centos/5.5/os/SRPMS/libevent-1.4.13-1.src.rpm
If you have experience in buildling packages from a tarball, using rpm to build software is not much of a leap really. It will never be as simple as installing a premade binary package, however.
I use checkinstall on Debian. It should not be so different on CentOS. I use it like that:
./configure
make
sudo checkinstall make install # fakeroot in place of sudo works usally for more security
# install the package generated