yes, i've read the online docs and followed a link or two to find a simple way to do this, such as:
http://sourceware.org/systemtap/wiki/SystemTapOnCentOS
so, these days, is that the canonical way to download source rpms? now, note that i'm not arguing about whether this is a good idea. in my circumstances, i want the ability to just "yum download" source rpms so that i can have my students poke around in a source rpm and learn how to build one, nothing more.
so, is that reasonable? to just manually add an extra repo file according to that link above (which appears to work perfectly well). frankly, the wiki page on downloading from source:
http://wiki.centos.org/PackageManagement/SourceInstalls
seems just a touch on the hysterical side. i don't disagree that installing packages from the source rpm is probably a questionable idea. but that doesn't justify simply not explaining how to do it easily.
my plan is to install yum-utils to get yumdownloader, add the repo file suggested above, then have students:
$ yumdownloader --source <package>
so they can examine the source of some packages. is the approach i'm suggesting reasonable? thanks.
rday
On Sun, 10 Oct 2010, Robert P. J. Day wrote:
so, these days, is that the canonical way to download source rpms?
I am substantially certain we have a wiki article on mirroring, and certainly I've written about mirroring over and over again from many approaches [my most recent blog post, aggregated by http://planet.centos.org/ has a recap at the bottom of some of those articles]. wget, lftp, and lynx all work fine. Of course RPM itself is a fine retrieval tool as well and has been __forever__
so, is that reasonable? to just manually add an extra repo file according to that link above (which appears to work perfectly well).
It is reasonable only if the user also has the willingness and skills to self-support. We don't (and cannot) support what we dont ship
frankly, the wiki page on downloading from source:
http://wiki.centos.org/PackageManagement/SourceInstalls
seems just a touch on the hysterical side. i don't disagree that installing packages from the source rpm is probably a questionable idea. but that doesn't justify simply not explaining how to do it easily.
"Here is a gun, and bullets. Leave it unloaded and in a locked case" and it is perfectly harmless
Add another random 'find' and 'great tip to stop RPM from carping about dependencies'with the "--nodeps", and BANG, your system is dead. It is all CentOS and RPM's fault, of course - "dependency hell, don't you know"
Yeah -- I know where I am going to send support load, going forward, who is not so hysterical
WHAT? you don't want to handle that load RIGHT NOT and for FREE, and on a newbies mis- and partial-information? hunh
-- Russ herrold
On Sun, 2010-10-10 at 17:56 -0400, Robert P. J. Day wrote:
so, is that reasonable? to just manually add an extra repo file according to that link above (which appears to work perfectly well).
In my opinion, in most cases there is no particularly good reason to bother compiling a source rpm yourself unless it's something that's not already in a repository.
If what you need is not in one of the repositories, then my next step is to either download a src.rpm from somewhere else (fedora, etc.) and see what it takes to compile that, or download the tar archive and see if I can find a .spec file somewhere that does something close to what I'm trying to accomplish. Sometimes there is an old version or a MDK source rpm that contains a .spec file that will provide a starting point. If not, then if it's not a really complex install you can just copy a spec file from another not really complex rpm and use that for a framework.
frankly, the wiki page on downloading from source:
http://wiki.centos.org/PackageManagement/SourceInstalls
seems just a touch on the hysterical side.
Sounds like pretty good advice to me. I try really hard to install stuff through rpm's. The only exception is with single-executable programs that can just be tossed into /usr/local/bin or ~/bin or whatever; those are generally programs that I have written myself or little utilities downloaded from here and there.
If it's a single-executable program without a bunch of support files and whatnot, and if I'm planning to install it on only one or two computers, then it's probably not worth the effort to create a rpm for it. Anything else, is.
On Sun, 10 Oct 2010, Frank Cox wrote:
On Sun, 2010-10-10 at 17:56 -0400, Robert P. J. Day wrote:
so, is that reasonable? to just manually add an extra repo file according to that link above (which appears to work perfectly well).
In my opinion, in most cases there is no particularly good reason to bother compiling a source rpm yourself unless it's something that's not already in a repository.
but no one is suggesting that you always want to *compile* a source rpm. perhaps you just want to examine the source, or do a prep, or something.
more to the point, it's a little disturbing that the general attitude here seems to be one of, "we don't think you should be doing something, so we're not going to tell you how to do it." and some people here wonder why others might want to write their own online centos howtos rather than contribute to centos.org? geez, feel free to stop wondering.
if it makes it easier, perhaps that wiki page could be retitled something more general, such as "working with source rpms." then it could cover simple repo setup and downloading and, with a suitable warning, also cover building. but it's a little high-handed to not explain how to do something because you've decided it's not something you want *others* to know.
rday
On Sun, 2010-10-10 at 18:58 -0400, Robert P. J. Day wrote:
but it's a little high-handed to not explain how to do something because you've decided it's not something you want *others* to know.
There is very little to explain, if all you want to do is examine the source.
Install rpmdevtools. Run rpmdev-setuptree
Pick your favourite mirror. Navigate to the src directory that you're interested in, download the src.rpm
rpm -i whatever.src.rpm
Your rpm contents are now in ~/rpmbuild. Examine away. The spec is in ~/rpmbuild/SPECS, the source code is in ~/rpmbuild/SOURCES
Compile it with rpmbuild -ba whatever.spec. Your binary will be in ~/rpmbuild/RPMS and the new src.rpm is in ~/rpmbuild/SRPMS.
On Sun, 2010-10-10 at 17:36 -0600, Frank Cox wrote:
On Sun, 2010-10-10 at 18:58 -0400, Robert P. J. Day wrote:
but it's a little high-handed to not explain how to do something because you've decided it's not something you want *others* to know.
There is very little to explain, if all you want to do is examine the source.
Install rpmdevtools. Run rpmdev-setuptree
---- Really?
]$ yum search rpmdevtools Loaded plugins: fastestmirror addons | 951 B 00:00 base | 2.1 kB 00:00 extras | 2.1 kB 00:00 updates | 1.9 kB 00:00 Excluding Packages in global exclude list Finished Warning: No matches found for: rpmdevtools No Matches found
John
On Sun, Oct 10, 2010 at 8:23 PM, JohnS jses27@gmail.com wrote:
On Sun, 2010-10-10 at 17:36 -0600, Frank Cox wrote:
On Sun, 2010-10-10 at 18:58 -0400, Robert P. J. Day wrote:
but it's a little high-handed to not explain how to do something because you've decided it's not something you want *others* to know.
There is very little to explain, if all you want to do is examine the source.
Install rpmdevtools. Run rpmdev-setuptree
Really?
]$ yum search rpmdevtools Loaded plugins: fastestmirror addons | 951 B 00:00 base | 2.1 kB 00:00 extras | 2.1 kB 00:00 updates | 1.9 kB 00:00 Excluding Packages in global exclude list Finished Warning: No matches found for: rpmdevtools No Matches found
John
rpmdevtools is in the epel repo so if you dont have epel installed and setup you wont see it with a yum search
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Shaun Jones wrote:
On Sun, Oct 10, 2010 at 8:23 PM, JohnS jses27@gmail.com wrote:
Warning: No matches found for: rpmdevtools No Matches found
John
Rpmdevtools for CentOS is available from EPEL.
http://wiki.centos.org/AdditionalResources/Repositories
http://fedoraproject.org/wiki/EPEL
http://fedoraproject.org/wiki/Rpmdevtools
On Sun, 10 Oct 2010, JohnS wrote:
On Sun, 2010-10-10 at 17:36 -0600, Frank Cox wrote:
There is very little to explain, if all you want to do is examine the source.
Install rpmdevtools. Run rpmdev-setuptree
Warning: No matches found for: rpmdevtools No Matches found
As I recall, rpmdevtools is a Fedora-ism
The actions in question set up a local %{_topdir} and then the RPMS, SOURCES, SPECS and so forth directories for a local user
[root@trap64 log]# su - herrold [herrold@trap64 ~]$ cat .rpmmacros %_topdir /home/herrold/rpmbuild %make make %dist orc %releasetagsuffix orc %vendor %{dist} # [herrold@trap64 ~]$ ls -l ~/rpmbuild/ total 40 drwxrwxr-x 8 herrold herrold 4096 Oct 10 21:12 BUILD drwxrwxr-x 4 herrold herrold 4096 Oct 4 16:53 RPMS drwxrwxr-x 3 herrold herrold 4096 Oct 10 21:12 SOURCES drwxrwxr-x 2 herrold herrold 4096 Oct 10 21:12 SPECS drwxrwxr-x 2 herrold herrold 4096 Oct 10 21:12 SRPMS [herrold@trap64 ~]$
I think at one point the referenced package had a copy of a little script I've long since published at: ftp://ftp.owlriver.com/pub/local/COLUG/RPM-build-tree.txt itself based on a post on the mailing list rpm-list
-- Russ herrold
On Sun, 2010-10-10 at 21:35 -0400, R P Herrold wrote:
On Sun, 10 Oct 2010, JohnS wrote:
On Sun, 2010-10-10 at 17:36 -0600, Frank Cox wrote:
There is very little to explain, if all you want to do is examine the source.
Install rpmdevtools. Run rpmdev-setuptree
Warning: No matches found for: rpmdevtools No Matches found
As I recall, rpmdevtools is a Fedora-ism
The actions in question set up a local %{_topdir} and then the RPMS, SOURCES, SPECS and so forth directories for a local user
[root@trap64 log]# su - herrold [herrold@trap64 ~]$ cat .rpmmacros %_topdir /home/herrold/rpmbuild %make make %dist orc %releasetagsuffix orc %vendor %{dist} # [herrold@trap64 ~]$ ls -l ~/rpmbuild/ total 40 drwxrwxr-x 8 herrold herrold 4096 Oct 10 21:12 BUILD drwxrwxr-x 4 herrold herrold 4096 Oct 4 16:53 RPMS drwxrwxr-x 3 herrold herrold 4096 Oct 10 21:12 SOURCES drwxrwxr-x 2 herrold herrold 4096 Oct 10 21:12 SPECS drwxrwxr-x 2 herrold herrold 4096 Oct 10 21:12 SRPMS [herrold@trap64 ~]$ RPM-build-tree.txt I think at one point the referenced package had a copy of a little script I've long since published at: ftp://ftp.owlriver.com/pub/local/COLUG/RPM-build-tree.txt
itself based on a post on the mailing list rpm-list
-- Russ herrold
---- :-) Well I knew where it was, it's just not in the distro. (fedorism) He would yet be stuck installing another repo for the people. Would be easier to use your Russ RPM-build-tree.txt script for him to do it. I like this option also added to it "%_tmppath" /foo/hoo ....
John
On Sun, Oct 10, 2010 at 05:56:47PM -0400, Robert P. J. Day wrote:
my plan is to install yum-utils to get yumdownloader, add the repo file suggested above, then have students:
Are these students paying for whatever training you are supplying?
John
On Sun, 10 Oct 2010, John R. Dennison wrote:
On Sun, Oct 10, 2010 at 05:56:47PM -0400, Robert P. J. Day wrote:
my plan is to install yum-utils to get yumdownloader, add the repo file suggested above, then have students:
Are these students paying for whatever training you are supplying?
and on that patronizing, condescending note, this list has pretty much outlived its usefulness.
rday
Before yum and when I used to have time for it, I compiled from source everything on my machine. It wasn't that big of a deal. Just took some time. The pay-off was significant in performance and speed... reason being that, if you configure gcc for your particular cpu, the code is able to take advantage of the hard-wired instruction set particular to your cpu which don't exist in the generic cpu the repo binaries are compiled for.
IIRC, just to get the source code out of an rpm you could download the source rpm and simply do
rpm -i /path/to/package.src.rpm
or in one step do
rpm -i ftp://path/to/package.src.rpm
Alternatively, you could also check out Slackware. The last time I looked at it (several years ago) it didn't use rpm or apt or any package management system at all, just tgz files. This is what Linux used to be before there was a redhat... and it's generally how code files are handled in development before they become rpms... or whatever.
Source code shouldn't scare anyone. It's interesting stuff and harmless... just text files, after all. If your students are going to hack around with it and compile it (which I would hope they would do), then of course you'll want to take appropriate measures.
More people should be doing this kind of stuff. The world needs more open source developers. Looking at existing code is a great tool for learning.
More people should be doing this kind of stuff. The world needs more open source developers. Looking at existing code is a great tool for learning.
+1
As Karanbir put it in his interview in Distrowatch a few months ago, CentOS is not only great as a stable and predictable server distrib, but can also serve as a basis for going further in one particular area, leaving the rest rock solid and untouched.
- create rpmbuild environment as here: http://wiki.centos.org/HowTos/SetupRpmBuildEnvironment - install 'mock' (IMPORTANT: install the one from CentOS, exclude the one from EPEL in your repo file)
- download SRPM(s) - (optional) if taken from Fedora after around 9 or 10, rpm -i *.src.rpm won't work, unpack it manually with Archive Manager, put the spec file in SPECS, the rest in SOURCES - download the latest source, or hack the spec file, etc. - create the SRPM: rpmbuild -bs --nodeps rpmbuild/SPECS/myspecfile.spec - build the SRPM you just created in mock (with debug option enabled to see all the logs, but they will also be in build.log) - do it over and over until your build dependencies are right and it completely builds - retrieve your RPMs, put them in a directory, use 'createrepo' to create metadata, use this directory as an additional repo for mock (update /etc/mock/*.cfg) - create a virtual machine (using KVM, VirtualBox, ...) - install your binaries RPM in the virtual machine (you could expose the above created local repo via httpd or NFS) - break your dummy virtual machine as much as you want - if what you have done could be useful to someone else, you are free to redistribute it (http://www.gnu.org/philosophy/free-sw.html), just be clear that it is not supported CentOS, especially if you updated core parts (*-plus repositories)
[1] building in mock is really efficient and clean: it takes care of the dependencies in a clean chrooted install, otherwise you end up having plenty of build dependencies on your workstation and if you have to build the dependency of the dependency of the dependency, install it in order to build the next one, etc. you're pretty much sure to break your workstation. You can use 'mock shell' to go and build manually in the chrooted install in case something went wrong and you want to study it without redoing the whole process.
On 10/11/2010 07:10 AM, Mathieu Baudier wrote: [snip]
- install 'mock' (IMPORTANT: install the one from CentOS, exclude the
one from EPEL in your repo file)
Would you mind giving a hint why one should not use mock from EPEL? Afaict the mock version in the CentOS repo is 0.6.13 which was released years ago and the one in EPEL is 1.0.7 which is current.
Thanks, Patrick
Would you mind giving a hint why one should not use mock from EPEL?
Because the one in CentOS will, out of the box, pull out and properly configure the CentOS buildsys package, which itself is a meta-package whose dependencies are the minimal set required to create a chroot build environment: http://dev.centos.org/centos/buildsys/5/
My understanding (to be confirmed/infirmed by CentOS developers) is that this is the tool actually used to build CentOS.
Afaict the mock version in the CentOS repo is 0.6.13 which was released years ago and the one in EPEL is 1.0.7 which is current.
Yes, that's what I thought first as well, but the one from CentOS worked, while the one from EPEL did not (for the purpose of building CentOS RPMS => I don't say that EPEL's mock is broken).
I tried to tweak it a bit, but in the end all that you need is a cleanly prepared chroot and the CentOS mock is good enough for that. (there is probably a way to get the EPEL one to work as well.)
Hence the need to exclude the mock from EPEL in the repo file, otherwise it updates the one from CentOS.
On Mon, 11 Oct 2010, Patrick Lists wrote:
Would you mind giving a hint why one should not use mock from EPEL? Afaict the mock version in the CentOS repo is 0.6.13 which was released years ago and the one in EPEL is 1.0.7 which is current.
ehh??
mock-1.1.5-1orc.src.rpm from upstream Raw Hide
The mock inplementaion is a moving target --- I do not know the particulars of why the other party recommmended using THE ONE CENTOS BUILT ON for CentOS, but ...
-- Russ herrold
On 10/11/2010 05:12 PM, R P Herrold wrote:
On Mon, 11 Oct 2010, Patrick Lists wrote:
Would you mind giving a hint why one should not use mock from EPEL? Afaict the mock version in the CentOS repo is 0.6.13 which was released years ago and the one in EPEL is 1.0.7 which is current.
ehh??
mock-1.1.5-1orc.src.rpm from upstream Raw Hide
I'm aware of the 1.1 branch but the mock website says that 1.1 is for "F-13+". Doesn't that excludes CentOS?
The mock inplementaion is a moving target --- I do not know the particulars of why the other party recommmended using THE ONE CENTOS BUILT ON for CentOS, but ...
Sorry but I don't get it. Are you saying that mock from EPEL or the Rawhide one you mentioned work equally fine on CentOS (5.5) and all cover the buildsys requirement that Mathieu mentioned?
Regards, Patrick
On Mon, 11 Oct 2010, Patrick Lists wrote:
On 10/11/2010 05:12 PM, R P Herrold wrote:
The mock inplementaion is a moving target --- I do not know the particulars of why the other party recommmended using THE ONE CENTOS BUILT ON for CentOS, but ...
Sorry but I don't get it. Are you saying that mock from EPEL or the Rawhide one you mentioned work equally fine on CentOS (5.5) and all cover the buildsys requirement that Mathieu mentioned?
not at all -- I am saying that mock is a moving target as to bugs, features, and approach if you move beyond the one we ship in (as I recall) 'extras'
In such cases the proper support venue regarding mock use is elsewhere, as we at centos are focused on supporting what we ship, rather than trying to know an answer for all bugs in all variations of all software everywhere
-- Russ herrold
On 11/10/10 10:44 AM, ken wrote:
Alternatively, you could also check out Slackware.
In my opinion Slackware is still the best distribution for actually learning about GNU/Linux. I'm a little biased, though, I've been running it since 4.0 (and had accounts on other systems running it prior to that).
The last time I looked at it (several years ago) it didn't use rpm or apt or any package management system at all, just tgz files.
Recently that's changed to .txz for the greater level of compression, but oterwise it's the same. Pkgtool is really simple and straight forward.
This is what Linux used to be before there was a redhat... and it's generally how code files are handled in development before they become rpms... or whatever.
Slack is great because of its strong adherance to the KISS principle.
Source code shouldn't scare anyone. It's interesting stuff and harmless... just text files, after all. If your students are going to hack around with it and compile it (which I would hope they would do), then of course you'll want to take appropriate measures.
Yep. I still don't see why some people are so afraid of:
./configure [options] make make install [make clean]
If it doesn't work it will tell you.
Regards, Ben
Robert P. J. Day wrote on 10/10/2010 05:56 PM: ...
http://wiki.centos.org/PackageManagement/SourceInstalls
seems just a touch on the hysterical side. i don't disagree that installing packages from the source rpm is probably a questionable idea. but that doesn't justify simply not explaining how to do it easily.
I think you missed the main point of that page. It is about (not) installing from source tarballs, although using packages from a reliable repo if available is good advice anyway. Perhaps that page would benefit from a link to
http://wiki.centos.org/HowTos/RebuildSRPM
That is only one hop away via the RPMs link that is on the SourceInstalls page.
Any comments on the latter page are welcome, but probably best done on the centos-docs list.
Phil
On Sunday, October 10, 2010 05:56:47 pm Robert P. J. Day wrote:
frankly, the wiki page on downloading from source: http://wiki.centos.org/PackageManagement/SourceInstalls seems just a touch on the hysterical side.
For certain uses and certain software stacks from source is the only sane way. For other stacks and uses the opposite is true. Plone from the Plone.org UnifiedInstaller is one stack where you simply want to stay with a from-source managed-by-zc.buildout setup, not from RPM's. It is one of the very few cases where this is so. In that case you have to balance support from the OS versus support from the Plone upstream; in the case of Plone upstream is preferred. YMMV.
i don't disagree that installing packages from the source rpm is probably a questionable idea. but that doesn't justify simply not explaining how to do it easily.
The referenced wiki page has nothing to do with rebuilding a source RPM, but has to do with the 'traditional' ./configure&&make&& sudo make install mantra that is a support nightmare.
Properly controlling from source-rpm builds is a sane activity, as long as you take the responsibility for the package, set the EVR for the RPM properly, etc. Good info on how to do this is in the Fedora developer docs. EPEL contains all the rpm developer tools you need, so enable EPEL, load rpmdevtools, and have fun. Support is in your own hands, of course. When there are specific options I need (like building a package with a non-default set of compile-time arguments or modules) I'll do this myself, and keep all the changes in my own setup with EVR > the CentOS package EVR (twiddling epoch, though really really ugly, is quite effective to make you package always win the comparison).
But I packaged PostgreSQL for five years, and am not a novice. I'm not as in practice as I once was, but I do try to keep up with most of the current ways of doing things. And I always try to start with the CentOS base package where possible.
my plan is to install yum-utils to get yumdownloader, add the repo file suggested above, then have students:
$ yumdownloader --source <package>
so they can examine the source of some packages. is the approach i'm suggesting reasonable? thanks.
Very reasonable for a learning tool, which is what your question was really asking. Not as reasonable for a production server.
Do use the Fedora/EPEL rpmdevtools, though.
-
Ben McGinnes -
Frank Cox -
John R. Dennison -
JohnS -
ken -
Lamar Owen -
Larry Brower -
Mathieu Baudier -
Patrick Lists -
Phil Schaffner -
R P Herrold -
R P Herrold -
Robert P. J. Day -
Shaun Jones