How do I best encourage maintainers to update the software they are responsible for in various repositories?
Akema Yagi made sure kmod-jfs for CentOS 7 was updated amazingly fast which is greatly appreciated. On the other hand, I have requested updates of some other software packages and have heard absolutely nothing in months...
On Fri, 27 Oct 2017 17:32:03 -0400 H wrote:
How do I best encourage maintainers to update the software they are responsible for in various repositories?
If it's something that you need or want and it's not available in a repo that you currently use you can compile it yourself.
I do that with a number of packages that are either newer or simply not available in the various Centos repos. In many cases it's as easy as downloading a new tar source file and adding it to the existing source rpm, doing three seconds of editing on the spec file to account for the new update, and compiling the result. Sometimes it's even easier -- just download a newer Fedora rpm and compile that on your Centos system.
On October 27, 2017 5:54:45 PM EDT, Frank Cox theatre@sasktel.net wrote:
On Fri, 27 Oct 2017 17:32:03 -0400 H wrote:
How do I best encourage maintainers to update the software they are responsible for in various repositories?
If it's something that you need or want and it's not available in a repo that you currently use you can compile it yourself.
I do that with a number of packages that are either newer or simply not available in the various Centos repos. In many cases it's as easy as downloading a new tar source file and adding it to the existing source rpm, doing three seconds of editing on the spec file to account for the new update, and compiling the result. Sometimes it's even easier -- just download a newer Fedora rpm and compile that on your Centos system.
-- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
These are software packages listed in various repositories, thus ostensibly maintained...
On 10/28/2017 11:33 AM, H wrote:
On October 27, 2017 5:54:45 PM EDT, Frank Cox theatre@sasktel.net wrote:
On Fri, 27 Oct 2017 17:32:03 -0400 H wrote:
How do I best encourage maintainers to update the software they are responsible for in various repositories?
If it's something that you need or want and it's not available in a repo that you currently use you can compile it yourself.
I do that with a number of packages that are either newer or simply not available in the various Centos repos. In many cases it's as easy as downloading a new tar source file and adding it to the existing source rpm, doing three seconds of editing on the spec file to account for the new update, and compiling the result. Sometimes it's even easier -- just download a newer Fedora rpm and compile that on your Centos system.
In a lot of instances, the upstream program's project that maintains it prohibits upgrades / updates by the requirements for their software.
Sometimes it will require a newer gcc to compile, or a newer php to run, or newer gtk+ or newer something else. This would require many changes to build on older versions of shared libraries in Enterprise Linux distros. This is a choice by the project that controls that software.
Backporting (https://access.redhat.com/security/updates/backporting) is very difficult, and is a main reason that RHEL needs to be a paid for service. People want stable, long lived software that is secure for the enterprise. That is the whole purpose of this type of distribution. You can't really expect repo maintainers to have the skills or time to backport newer software to an Enterprise distro. If the project that maintains that software wants it to work in the enterprise, they should maintain long term support for their software.
On 10/27/2017 2:54 PM, Frank Cox wrote:
I do that with a number of packages that are either newer or simply not available in the various Centos repos. In many cases it's as easy as downloading a new tar source file and adding it to the existing source rpm, doing three seconds of editing on the spec file to account for the new update, and compiling the result. Sometimes it's even easier -- just download a newer Fedora rpm and compile that on your Centos system.
It would be nice if this remained even a *suggestion* at the Fedora layer, but there seems to be from occasional obliviousness to outright hostility to the idea of keeping spec files broadly compatible across a range of downstream releases and for other RPM-based distributions, or not ripping out compatibility at Fedora-speed. (Even leaving aside "burn-the-ships" actions like outright banning SysV init scripts.)
It didn't seem to use to be that case. IMO it makes a lot more sense to wrap distro-specific .spec file changes in conditionals and let the rpmbuild do the right thing than to post and maintain separate versions for Fedora, EPEL, and anything else.
-jc
On 10/28/2017 12:28 PM, Japheth Cleaver wrote:
On 10/27/2017 2:54 PM, Frank Cox wrote:
I do that with a number of packages that are either newer or simply not available in the various Centos repos. In many cases it's as easy as downloading a new tar source file and adding it to the existing source rpm, doing three seconds of editing on the spec file to account for the new update, and compiling the result. Sometimes it's even easier -- just download a newer Fedora rpm and compile that on your Centos system.
It would be nice if this remained even a *suggestion* at the Fedora layer, but there seems to be from occasional obliviousness to outright hostility to the idea of keeping spec files broadly compatible across a range of downstream releases and for other RPM-based distributions, or not ripping out compatibility at Fedora-speed. (Even leaving aside "burn-the-ships" actions like outright banning SysV init scripts.)
It didn't seem to use to be that case. IMO it makes a lot more sense to wrap distro-specific .spec file changes in conditionals and let the rpmbuild do the right thing than to post and maintain separate versions for Fedora, EPEL, and anything else.
If people want all the newer packages that exist in Fedora .. why not just use Fedora?
Enterprise distributions are designed to be maintained for 10 years so when you make an investment of X million dollars in a piece of software, you can use it for an extended period of time. Having all the latest packages is not what Enterprise Linux is about. That is what Fedora is about.
Fedora has introduced a new feature called modularity (https://docs.pagure.org/modularity/). Eventually, when / if modularity is rolled into Red Hat Enterprise Linux, you will get some more flexibility in RHEL (and therefore CentOS as we use RHEL sources).
CentOS Linux is a great Linux distribution. We want everyone to use it. But trying to convert CentOS Linux into Fedora is not only redundant (Fedora already exists .. use it) .. a bastardized version of CentOS with hundreds of newer manually maintained components is not really CentOS, and Fedora is likely more stable than that monstrosity anyway.
There are things to add newer pieces to CentOS (SCL SIG, PaaS SIG, etc.), and those can be done now and integrated into the Enterprise Distro. If those are what you need, that is what they're for.
On Sat, 28 Oct 2017 13:07:41 -0500 Johnny Hughes wrote:
But trying to convert CentOS Linux into Fedora is not only redundant (Fedora already exists .. use it) .. a bastardized version of CentOS with hundreds of newer manually maintained components is not really CentOS, and Fedora is likely more stable than that monstrosity anyway.
There's a difference between upgrading core operating system functionality and a changing a few userland programs. I compile the latest versions of Sylpheed and astyle (for example) and use those programs on my Centos 7 desktop computer. I don't see any issue with doing things like this and don't believe that it decreases the stability of the system.
I don't want to tear my whole computer down and upgrade my operating system every six months, and I don't want to deal with the bleeding-edge stuff that might or might not work when it affects something like network connectivity or whether I actually get a picture on the screen when I boot up my computer. But for userland programs, why not run the latest version of Libreoffice or Cool Reader if it's easy to compile them and I can get a few new features out of it?
On 10/28/2017 01:36 PM, Frank Cox wrote:
On Sat, 28 Oct 2017 13:07:41 -0500 Johnny Hughes wrote:
But trying to convert CentOS Linux into Fedora is not only redundant (Fedora already exists .. use it) .. a bastardized version of CentOS with hundreds of newer manually maintained components is not really CentOS, and Fedora is likely more stable than that monstrosity anyway.
There's a difference between upgrading core operating system functionality and a changing a few userland programs. I compile the latest versions of Sylpheed and astyle (for example) and use those programs on my Centos 7 desktop computer. I don't see any issue with doing things like this and don't believe that it decreases the stability of the system.
I don't want to tear my whole computer down and upgrade my operating system every six months, and I don't want to deal with the bleeding-edge stuff that might or might not work when it affects something like network connectivity or whether I actually get a picture on the screen when I boot up my computer. But for userland programs, why not run the latest version of Libreoffice or Cool Reader if it's easy to compile them and I can get a few new features out of it?
And as long as that works and they compile against the base shared libraries, that is fine.
But that is usually NOT the case and newer versions of LibreOffice or the others usually need a newer gtk or newer something else, etc.
I am all for adding content that does not exist .. if there is a long term upstream for it. I am, for example, adding a 4.9.x LTS kernel for newer x86_64 or i386 embedded type boards that can also be used on newer hardware if required (https://wiki.centos.org/SpecialInterestGroup/AltArch/i386 , see Experimental Repository)
But, it took me longer (and more effort) to make that one package work with CentOS Linux 7 than it took for me to create the first 7.0.1406 tree.
On Sat, Oct 28, 2017 at 12:36:33PM -0600, Frank Cox wrote:
I don't want to tear my whole computer down and upgrade my operating system every six months, and I don't want to deal with the bleeding-edge stuff that might or might not work when it affects something like network connectivity or whether I actually get a picture on the screen when I boot up my computer. But for userland programs, why not run the latest version of Libreoffice or Cool Reader if it's easy to compile them and I can get a few new features out of it?
This is one of the reasons I'm in favor of bringing Flatpak to Fedora (and presumably also eventually to CentOS). We have a project to automatically convert Fedora packages to Flatpaks, which you could then run on a CentOS base.
That's really just an approach for desktop apps, though. Fedora Modularity aims to solve this for other software stacks, allowing you to keep longer-lived streams for the stuff you don't want to change, and faster streams for the stuff you do want different.
All that said, I do also feel *some* need to mention that Fedora gives you a 13-month lifecycle, not six months. And, in most cases, you can upgrade in under half an hour without no fuss.
On 10/28/2017 02:07 PM, Johnny Hughes wrote:
On 10/28/2017 12:28 PM, Japheth Cleaver wrote:
On 10/27/2017 2:54 PM, Frank Cox wrote:
I do that with a number of packages that are either newer or simply not available in the various Centos repos. In many cases it's as easy as downloading a new tar source file and adding it to the existing source rpm, doing three seconds of editing on the spec file to account for the new update, and compiling the result. Sometimes it's even easier -- just download a newer Fedora rpm and compile that on your Centos system.
It would be nice if this remained even a *suggestion* at the Fedora layer, but there seems to be from occasional obliviousness to outright hostility to the idea of keeping spec files broadly compatible across a range of downstream releases and for other RPM-based distributions, or not ripping out compatibility at Fedora-speed. (Even leaving aside "burn-the-ships" actions like outright banning SysV init scripts.)
It didn't seem to use to be that case. IMO it makes a lot more sense to wrap distro-specific .spec file changes in conditionals and let the rpmbuild do the right thing than to post and maintain separate versions for Fedora, EPEL, and anything else.
If people want all the newer packages that exist in Fedora .. why not just use Fedora?
Enterprise distributions are designed to be maintained for 10 years so when you make an investment of X million dollars in a piece of software, you can use it for an extended period of time. Having all the latest packages is not what Enterprise Linux is about. That is what Fedora is about.
Fedora has introduced a new feature called modularity (https://docs.pagure.org/modularity/). Eventually, when / if modularity is rolled into Red Hat Enterprise Linux, you will get some more flexibility in RHEL (and therefore CentOS as we use RHEL sources).
CentOS Linux is a great Linux distribution. We want everyone to use it. But trying to convert CentOS Linux into Fedora is not only redundant (Fedora already exists .. use it) .. a bastardized version of CentOS with hundreds of newer manually maintained components is not really CentOS, and Fedora is likely more stable than that monstrosity anyway.
There are things to add newer pieces to CentOS (SCL SIG, PaaS SIG, etc.), and those can be done now and integrated into the Enterprise Distro. If those are what you need, that is what they're for.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Well, I am trying to get a couple of applications compiled that I believe are quite compatible with the positioning of CentOS:
- The graphical configuration utility for fcitx (fcitx-configtool) is missing and any configuration presently has to be done by manually editing the complex configuration files which are very poorly documented. Thus configuration of fcitx for e.g. entering/editing Chinese text took a long time and I still have a couple of issues that I have been unable to resolve.
- The geany editor is missing the markdown plugin, this however, may shortly be resolved.
- I'd love to have keepassx updated so bugs are fixed and the file format becomes compatible with the file format used by its Windows counterpart and files thus interchanged without any problems.
- pdfshuffler is not available for CentOS 7, only CentOS 6.
On Sat, 28 Oct 2017 17:15:01 -0400 H wrote:
The graphical configuration utility for fcitx (fcitx-configtool) is missing
I don't know anything about Chinese text rendering.
- The geany editor is missing the markdown plugin, this however, may shortly
be resolved.
Check on my website. :)
The rest of your stuff is easily dealt with by compiling the relevant Fedora rpms.
I'd love to have keepassx updated
Download this:
ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/Everything/source/tree/Packages/k/keepassx-2.0.3-1.fc25.src.rpm
and you can have this:
keepassx-2.0.3-1.el7.centos.x86_64.rpm
I just tried it and it took only a few minutes.
- pdfshuffler is not available for CentOS 7, only CentOS 6.
I just compiled this
ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/Everything/source/tree/Packages/p/pdfshuffler-0.6.0-9.fc25.src.rpm
It took about three seconds to do the whole job and now I have this:
pdfshuffler-0.6.0-9.el7.centos.noarch.rpm
You can easily do the same if you wish. Just install rpmdevtools and any necessary dependencies for the rpm that you want to compile and off you go. The rpmbuild command will even tell you about any missing dependencies. For example, my first attempt at compiling keepassx told me:
error: Failed build dependencies: libXtst-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64 libgcrypt-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64
To fix it I did this:
yum install libXtst-devel libgcrypt-devel
My next attempt to compile the keepassx rpm worked.
This isn't a guaranteed solution for absolutely every rpm or program that you might ever come across; sometimes you get into a dependency rabbit hole that never seems to end and it becomes more work than it's worth to solve. Other times you get stuff that requires a newer or different version of something that's way too much work to upgrade or change. But in a lot of cases, you can just download and compile your own rpm as needed. As you see here, two items on your wish list are easily handled this way in less than five minutes. It took me longer to write this email than it did to download and compile those programs.
On 10/28/2017 05:42 PM, Frank Cox wrote:
On Sat, 28 Oct 2017 17:15:01 -0400 H wrote:
The graphical configuration utility for fcitx (fcitx-configtool) is missing
I don't know anything about Chinese text rendering.
- The geany editor is missing the markdown plugin, this however, may shortly
be resolved.
Check on my website. :)
The rest of your stuff is easily dealt with by compiling the relevant Fedora rpms.
I'd love to have keepassx updated
Download this:
ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/Everything/source/tree/Packages/k/keepassx-2.0.3-1.fc25.src.rpm
and you can have this:
keepassx-2.0.3-1.el7.centos.x86_64.rpm
I just tried it and it took only a few minutes.
- pdfshuffler is not available for CentOS 7, only CentOS 6.
I just compiled this
ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/Everything/source/tree/Packages/p/pdfshuffler-0.6.0-9.fc25.src.rpm
It took about three seconds to do the whole job and now I have this:
pdfshuffler-0.6.0-9.el7.centos.noarch.rpm
You can easily do the same if you wish. Just install rpmdevtools and any necessary dependencies for the rpm that you want to compile and off you go. The rpmbuild command will even tell you about any missing dependencies. For example, my first attempt at compiling keepassx told me:
error: Failed build dependencies: libXtst-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64 libgcrypt-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64
To fix it I did this:
yum install libXtst-devel libgcrypt-devel
My next attempt to compile the keepassx rpm worked.
This isn't a guaranteed solution for absolutely every rpm or program that you might ever come across; sometimes you get into a dependency rabbit hole that never seems to end and it becomes more work than it's worth to solve. Other times you get stuff that requires a newer or different version of something that's way too much work to upgrade or change. But in a lot of cases, you can just download and compile your own rpm as needed. As you see here, two items on your wish list are easily handled this way in less than five minutes. It took me longer to write this email than it did to download and compile those programs.
The problem with compiling the relevant fedora SRPMs is .. once fedora moves to a version (in their tree) that no longer compiles on CentOS because of shared library issues, any security updates dry up. If you have not found an upstream (of Fedora) source for updates for that version of the software in question, you either have to learn how to backport (https://access.redhat.com/security/updates/backporting), live with software that contains security issues, or compile a newer version of Fedora's software. Many times, that means adding in a newer version of dependent shared libraries. And that can mean having to recompile other things that depended on the shared libraries that you upgraded (or building statically, etc.).
I recently had to go through that with the 3.18.x kernel that we used in the Xen4CentOS repo in the Virt SIG. I worked on another LTS kernel (4.9.x) for about a month before 3.18.x went EOL from kernel.org .. then it took us about another 2 months of testing in the Virt SIG to get a fairly stable kernel build that worked for the xen Dom0 kernel.
The reason that every package in Fedora which is removed from RHEL is not in EPEL is that it is very hard to properly backport items and find new streams of updates that can keep older ABI/API compatibility and main software secure after the project that maintains it moves on. It is also a major reason Red Hat employs thousands of engineers to do it and why people pay them billions of dollars a year to maintain it.
So yes, it can be done .. but if you are trying to do it for 10 or so years, it is not easy.
Frank please could you explain how to create rpms for el7 from fedora src.rpms?
On Sun, Oct 29, 2017 at 12:42 AM, Frank Cox theatre@sasktel.net wrote:
On Sat, 28 Oct 2017 17:15:01 -0400 H wrote:
The graphical configuration utility for fcitx (fcitx-configtool) is
missing
I don't know anything about Chinese text rendering.
- The geany editor is missing the markdown plugin, this however, may
shortly
be resolved.
Check on my website. :)
The rest of your stuff is easily dealt with by compiling the relevant Fedora rpms.
I'd love to have keepassx updated
Download this:
ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/ Everything/source/tree/Packages/k/keepassx-2.0.3-1.fc25.src.rpm
and you can have this:
keepassx-2.0.3-1.el7.centos.x86_64.rpm
I just tried it and it took only a few minutes.
- pdfshuffler is not available for CentOS 7, only CentOS 6.
I just compiled this
ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/ Everything/source/tree/Packages/p/pdfshuffler-0.6.0-9.fc25.src.rpm
It took about three seconds to do the whole job and now I have this:
pdfshuffler-0.6.0-9.el7.centos.noarch.rpm
You can easily do the same if you wish. Just install rpmdevtools and any necessary dependencies for the rpm that you want to compile and off you go. The rpmbuild command will even tell you about any missing dependencies. For example, my first attempt at compiling keepassx told me:
error: Failed build dependencies: libXtst-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64 libgcrypt-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64
To fix it I did this:
yum install libXtst-devel libgcrypt-devel
My next attempt to compile the keepassx rpm worked.
This isn't a guaranteed solution for absolutely every rpm or program that you might ever come across; sometimes you get into a dependency rabbit hole that never seems to end and it becomes more work than it's worth to solve. Other times you get stuff that requires a newer or different version of something that's way too much work to upgrade or change. But in a lot of cases, you can just download and compile your own rpm as needed. As you see here, two items on your wish list are easily handled this way in less than five minutes. It took me longer to write this email than it did to download and compile those programs.
-- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 10/29/2017 08:40 AM, vychytraly . wrote:
Frank please could you explain how to create rpms for el7 from fedora src.rpms?
Well, I am not Frank, but you download the SRPM (I use wget) and put it into a directory.
Then you extract it .. there are many ways to do that .. I do this:
rpm -Uvh --define "_topdir $(pwd)" --nodeps <srpm.name>
Then you have an exploded SRPM with a SPECS/ and SOURCES/ directory. You then need to edit the SPECS/<name>.spec file and verify each line in the spec file will work with EL7 instead of fc25 (or whatever version of Fedora you got the SRPM from). This includes but is not limited to knowing the differences in the rpm macros between that version of Fedora's rpmbuild and CentOS 7's rpmbuild .. what the versions of shared libraries (or other dependencies like python, etc.) are for that version of Fedora and CentOS 7 .. which one of those shared dependencies are required or can be degraded in version to the ones in CentOS 7.
Basically, the SRPMs from Fedora 18 generally had all the required dependencies for RHEL / CentOS for the 7.0 release cycle source code .. BUT with rebases in every point release since the 7.0 cycle,, that is no longer true. Now some components (like Gnome) have very newer dependencies while others still have the dependencies from Fedora 18.
Fedora 18 stopped getting updates and went EOL on 2014-01-14 .. any packages that you build based on those SRPMs need to get a new source code stream so that you can continue to get security fixes .. or you have to take the newer source code and backport the changes to the Fedora 18 based SRPMS .. or you have to get newer versions of the package and build it against the current CentOS 7 provided shared dependencies, upgrading any dependencies that are too old. THEN you have to rebuild any other packages in CentOS that used the older dependencies from CentOS 7 that you just upgraded. THEN you need to maintain not only the package that you wanted to build the way that you just did .. now you also need to maintain all those dependencies that way .. AND .. you need to maintain all of the new CentOS packages that you had to rebuild based on those dependencies in the same way. That could mean that to add one thing, you now need to maintain 20 packages.
And if you are taking things from Fedora 25 (as an example) to CentOS 7, you need to be concerned about things like .. a different location for kernel install tools .. a different major version of python (python2 vs python3) .. a majorly different version of GNOME and KDE, differences in samba, in NFS, etc. etc.
Again, that is why Red Hat has thousands of engineers to maintain the Enterprise Linux sources.
On Sun, 29 Oct 2017 14:40:56 +0100 vychytraly . wrote:
Frank please could you explain how to create rpms for el7 from fedora src.rpms?
The complexity of doing this will vary a lot with what you're trying to compile, but for userland programs like email clients, text editors, games and the like it can be very easy to do in a lot of cases.
As Johnny says, you don't really want to do this with core operating system functions since you can end up with a Frankenstein system that might not work properly any more.
In many cases (more than a few but by no means all) you can compile a Fedora rpm for Centos using the following procedure.
You need to have rpmdevtools installed:
yum install rpmdevtools
Now set up the build directory structure in your home directory:
rpmdev-setuptree
After that, download the Fedora srpm, then run a rpmbuild command against the rpm you downloaded:
rpmbuild -ba nameofsourcerpm.src.rpm
Now you see what happens. Sometimes the process will run and you'll end up with a rpm file in ~/rpmbuild/RPMS/. If so, then you're done. You've got the Centos rpm that you wanted.
If the process errors out then your next step depends on the nature of the error. If it's a missing dependency then you might be able to simply install that dependency:
yum install nameofdependency
Then run the rpmbuild command again and see if it works.
If you can't find a pre-built rpm of the missing dependency then you might be able to build it yourself using the above process. Or not. It depends on the circumstances and what's missing. If the program requires a newer version of a dependency that you already have installed, you might want to re-consier your plan at that point. See above about creating a Frankenstein system.
If the process errors out due to something other than a missing dependency, things become a bit more complex at that point. If you look in ~/rpmbuild/SPECS you will find a .spec file for your rpm. Crank up your text editor and inspect that and see what it's doing and where things go wrong. Sometimes it's useful to simply compile the original source file directly and see if that works. (You can find that in ~/rpmbuild/SOURCES. )
If the original source file compiles but the rpm doesn't, then there's likely a fix that you need to do to the spec file to make it work. Sometimes it's useful to compare the spec file for an older version that does work on Centos with the spec file for a newer version that doesn't, and see what changed.
If the source file doesn't compile then you have bigger problems to solve -- perhaps you need to patch the sources or perhaps it just plain won't work on Centos. That's the place where I'll usually give up unless it's really important to me to get it to work.
If it is really important (that doesn't happen very often) then I keep a sacrificial Centos 7 Virtual Box image that I can use to experiment with changing some of the stuff that's under the hood without worrying about blowing up my main desktop. But again, that doesn't happen very often.
Note that some Fedora stuff won't work on Centos. Period.
But some stuff will work just fine.
On Sun, 29 Oct 2017 14:40:56 +0100 vychytraly . wrote:
Frank please could you explain how to create rpms for el7 from fedora src.rpms?
The complexity of doing this will vary a lot with what you're trying to compile, but for userland programs like email clients, text editors, games and the like it can be very easy to do in a lot of cases.
As Johnny says, you don't really want to do this with core operating system functions since you can end up with a Frankenstein system that might not work properly any more.
In many cases (more than a few but by no means all) you can compile a Fedora rpm for Centos using the following procedure.
.........
Frank,
Thanks very much for explaining this process. I would like to have orthanc usable for Centos 7, but the epel repos only have it for Centos 6.
I will give your outline a try!!!
Greg
On 29 October 2017 at 13:40, vychytraly . vychytraly@gmail.com wrote:
Frank please could you explain how to create rpms for el7 from fedora src.rpms?
You may find this a useful read:
Thank you all very much for explaining this, it is very interesting topic :)
On Mon, Oct 30, 2017 at 12:27 PM, James Hogarth james.hogarth@gmail.com wrote:
On 29 October 2017 at 13:40, vychytraly . vychytraly@gmail.com wrote:
Frank please could you explain how to create rpms for el7 from fedora src.rpms?
You may find this a useful read:
https://www.hogarthuk.com/?q=node/11 _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 10/28/2017 06:42 PM, Frank Cox wrote:
On Sat, 28 Oct 2017 17:15:01 -0400 H wrote:
The graphical configuration utility for fcitx (fcitx-configtool) is missing
I don't know anything about Chinese text rendering.
- The geany editor is missing the markdown plugin, this however, may shortly
be resolved.
Check on my website. :)
The rest of your stuff is easily dealt with by compiling the relevant Fedora rpms.
I'd love to have keepassx updated
Download this:
ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/Everything/source/tree/Packages/k/keepassx-2.0.3-1.fc25.src.rpm
and you can have this:
keepassx-2.0.3-1.el7.centos.x86_64.rpm
I just tried it and it took only a few minutes.
- pdfshuffler is not available for CentOS 7, only CentOS 6.
I just compiled this
ftp://mirror.csclub.uwaterloo.ca/fedora/linux/releases/25/Everything/source/tree/Packages/p/pdfshuffler-0.6.0-9.fc25.src.rpm
It took about three seconds to do the whole job and now I have this:
pdfshuffler-0.6.0-9.el7.centos.noarch.rpm
You can easily do the same if you wish. Just install rpmdevtools and any necessary dependencies for the rpm that you want to compile and off you go. The rpmbuild command will even tell you about any missing dependencies. For example, my first attempt at compiling keepassx told me:
error: Failed build dependencies: libXtst-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64 libgcrypt-devel is needed by keepassx-1:2.0.3-1.el7.centos.x86_64
To fix it I did this:
yum install libXtst-devel libgcrypt-devel
My next attempt to compile the keepassx rpm worked.
This isn't a guaranteed solution for absolutely every rpm or program that you might ever come across; sometimes you get into a dependency rabbit hole that never seems to end and it becomes more work than it's worth to solve. Other times you get stuff that requires a newer or different version of something that's way too much work to upgrade or change. But in a lot of cases, you can just download and compile your own rpm as needed. As you see here, two items on your wish list are easily handled this way in less than five minutes. It took me longer to write this email than it did to download and compile those programs.
Thank you. I will set up the environment so I can compile apps on my computer.
On 10/28/2017 01:28 PM, Japheth Cleaver wrote:
It didn't seem to use to be that case. IMO it makes a lot more sense to wrap distro-specific .spec file changes in conditionals and let the rpmbuild do the right thing than to post and maintain separate versions for Fedora, EPEL, and anything else.
In my former role as package maintainer for the PostgreSQL development group several years ago, I was contracted to do RPMs for several different distributions. And while this was several years ago, the basic RPM mechansims have not changed that significantly, and this kind of maintenance can become a rat's nest nightmare very quickly. I found that, specifically for PostgreSQL, the complexity increase was not linearly proportional to the number of distributions and versions of distributions supported; rather, it was much more like a cubic or quartic relationship with multiple poles and zeroes (using Z transform terminology) and pitfalls everywhere. The current PostgreSQL RPm maintainers do a great job supporting what they do, but it is not easy at all to support more than four distribution versions with one spec file.
Now, this thread is also talking about doing your own rebuilds, and, to a point, this works quite well. Especially in cases where the EPEL maintainer simply refuses to update a package because it would cause a version bump of that particular package and 'version bumps require Deep Reasons' (paraphrased from an actual response). My experience maintaining the PostgreSQL RPMs prepared me well for some of the things I have rebuilt (such as kicad) on C7.
HOWEVER, there is a hard and fast and totally inviolate rule to rolling your own rebuilds: "You break it, you keep it." You are taking your own system's stability into your own hands; for some packages (like kicad, or gnuradio, or other relatively stand-alone packages that don't require major shared library replumbing) it's fairly easy and safe to do your own builds; for some packages it is going to be nearly impossible if the packages' upstream developers haven't made it easy to locally build their dependencies with the sometimes very specific version requirements (case in point: Ardour). And some of these packages have no security footprint as far as updates are concerned (web browsers and email clients absolutely have major security footprints and need to stay updated, but something like kicad does not).
There are automated tools to do these sorts of things, such as the perl script 'smock' which does a reasonable job doing source build dependencies, as long as the buildrequires deps in the source RPM are proper and there are no hidden ones (experienced RPM rebuilders know I say that a bit tongue in cheek). Whatever you do, do NOT rebuild as root. Mock and similar tools make it possible to have reproducible builds, and it is strongly encouraged that these tools be used.
BUT, again, "you break it, you keep it" applies strongly because that package you built might have required a package that isn't currently in C7 but might be added at some future date, and your hand-built package might cause a real security update to fail in weird ways. Caveat aedificator, perhaps? You are then responsible to keep your hand-built dependency updated yourself.
-
Frank Cox -
Gregory P. Ennis -
H -
James Hogarth -
Japheth Cleaver -
Johnny Hughes -
Lamar Owen -
Matthew Miller -
vychytraly .