Hi,
I was wondering if is or ever will be possible to install srpms using yum. In the yum manpage it says you can specify a package using 'package.arch', so I was wondering if that could be done with 'package.src'. I think this would really be a helpful feature. At the moment to get a srpm I have to go to one of the ftp mirrors, find the right folder then search for the right package among hundreds of other files.
n0dalus.
+1
On 11/27/05, n0dalus n0dalus+redhat@gmail.com wrote:
Hi,
I was wondering if is or ever will be possible to install srpms using yum. In the yum manpage it says you can specify a package using 'package.arch', so I was wondering if that could be done with 'package.src'. I think this would really be a helpful feature. At the moment to get a srpm I have to go to one of the ftp mirrors, find the right folder then search for the right package among hundreds of other files.
n0dalus.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sun, 2005-11-27 at 18:13 +1030, n0dalus wrote:
Hi,
I was wondering if is or ever will be possible to install srpms using yum. In the yum manpage it says you can specify a package using 'package.arch', so I was wondering if that could be done with 'package.src'. I think this would really be a helpful feature. At the moment to get a srpm I have to go to one of the ftp mirrors, find the right folder then search for the right package among hundreds of other files.
n0dalus.
yum install yum-utils yumdownloader --source package
On 11/27/05, Nicholas Miell nmiell@comcast.net wrote:
yum install yum-utils yumdownloader --source package
That's useful, thanks. Might this functionality ever be built into yum though?
n0dalus.
On Sun, 2005-11-27 at 19:02 +1030, n0dalus wrote:
On 11/27/05, Nicholas Miell nmiell@comcast.net wrote:
yum install yum-utils yumdownloader --source package
That's useful, thanks. Might this functionality ever be built into yum though?
no
-sv
On Sun, 27 Nov 2005, seth vidal wrote:
yum install yum-utils yumdownloader --source package
That's useful, thanks. Might this functionality ever be built into yum though?
no
That's a really good answer if you want developrs to feel that they are being taken seriously.....
Do you think there is a fundamental problem with people being able to get the sources easilly? Is yum fundamentally flawed for this? Is it too much work to put in yum?
We might appreciate decisions better if we know why they are made in a certain way.
Paul
On Mon, Nov 28, 2005 at 01:40:15AM +0100, Paul Wouters wrote:
Do you think there is a fundamental problem with people being able to get the sources easilly? Is yum fundamentally flawed for this? Is it too much work to put in yum? We might appreciate decisions better if we know why they are made in a certain way.
It's been discussed over and over; that's why Seth is being so abrupt. The archives to this list and the yum list are public, so you can certainly find out why they've been made.
The short answer is that it violates the principle of "do one thing and do it well". Adding features like this clutters up yum's interface, not to mention the internal code. Having it separate is cleaner.
On 11/28/05, Matthew Miller mattdm@mattdm.org wrote:
On Mon, Nov 28, 2005 at 01:40:15AM +0100, Paul Wouters wrote:
Do you think there is a fundamental problem with people being able to get the sources easilly? Is yum fundamentally flawed for this? Is it too much work to put in yum? We might appreciate decisions better if we know why they are made in a certain way.
It's been discussed over and over; that's why Seth is being so abrupt. The archives to this list and the yum list are public, so you can certainly find out why they've been made.
The short answer is that it violates the principle of "do one thing and do it well". Adding features like this clutters up yum's interface, not to mention the internal code. Having it separate is cleaner.
I did several searches in the archives (at gmane) but was unable to find anything... I guess I should have tried the yum list. I didn't it existed at the time though. I would like to add one thing to this discussion, and that is a quote from the GNU GPL: "If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code."
Notice "offering equivalent access to copy the source code from the same place". I'm not trying to say or imply that anything is violating the GPL here, but I think some users expect this equivalent access to mean that it's just as easy to get the source rpms. And I think the designated 'place' here is yum. In this essence I do not think this is outside of Fedora or yum's goals.
I am happy to accept a 'no' answer though, and thanks for your time.
n0dalus.
On Mon, Nov 28, 2005 at 12:50:59PM +1030, n0dalus wrote:
Notice "offering equivalent access to copy the source code from the same place". I'm not trying to say or imply that anything is violating the GPL here, but I think some users expect this equivalent access to mean that it's just as easy to get the source rpms. And I think the designated 'place' here is yum.
I've thought about this too, especially as things like "oh, the repo is actually provided via HTTP" become near-invisible (which is both inevitable and good as the infrastructure gets better). But I think having yum-utils able to do the job satisfies the issue quite nicely. It uses the exact same infrastructure, after all.
When, in the future, yum GUI tools become so good that most users don't even consider the command-line version, those GUI tools should consider this too, not just for the sake of hewing to a particular strong interpretation of the GPL, but because source access is an important part of the free software / open source culture, and it shouldn't be a buried secret option.
On Sun, 2005-11-27 at 19:49 -0500, Matthew Miller wrote:
The short answer is that it violates the principle of "do one thing and do it well". Adding features like this clutters up yum's interface, not to mention the internal code. Having it separate is cleaner.
I disagree. If being properly implemented, a "get srpms" operation would be a yum-library feature.
Whether to make such a functionality accessible to users as part of the "yum"-application or as a separate tool is a matter of taste. The effort of implementing both cases, would be almost identical.
However, refusing to implement such an (IMO) essential core-feature as part of yum-libs and wanting to push it to external packages (IMO) is not a wise decision.
Ralf
On Mon, 2005-11-28 at 01:40 +0100, Paul Wouters wrote:
On Sun, 27 Nov 2005, seth vidal wrote:
yum install yum-utils yumdownloader --source package
That's useful, thanks. Might this functionality ever be built into yum though?
no
That's a really good answer if you want developrs to feel that they are being taken seriously.....
Do you think there is a fundamental problem with people being able to get the sources easilly? Is yum fundamentally flawed for this? Is it too much work to put in yum?
We might appreciate decisions better if we know why they are made in a certain way.
It's really best discussed on appropriate list- yum-devel.
But to the point - we've discussed it there before. The reason it should not be in the yum program itself but in an add-on tool is that it unnecessarily clutters up the main program.
-sv
On Sun, 27 Nov 2005, seth vidal wrote:
It's really best discussed on appropriate list- yum-devel.
But to the point - we've discussed it there before. The reason it should not be in the yum program itself but in an add-on tool is that it unnecessarily clutters up the main program.
Okay. Thanks for the information.
Not that agree. The above sounds correct from the yum developers point of view, but fails to take into account the enduser who will expect to be able to use "the package manager" for such tasks.
There also seems to be no easy way for the user to figure out an additional tool is needed. Perhaps "yum install foo.src" and "yum -source install foo" could return some helpful information on how people are supposed to obtain the source in a somewhat automatic way.
I'm sure that does not add *that* much complexity to yum :)
Paul
On Mon, Nov 28, 2005 at 02:22:00AM +0100, Paul Wouters wrote:
Not that agree. The above sounds correct from the yum developers point of view, but fails to take into account the enduser who will expect to be able to use "the package manager" for such tasks.
I dunno. I expect an end-user savvy enough to use yum on the command line can figure it out fairly easily. And by extension, anyone savvy enough to have a use for source.
There also seems to be no easy way for the user to figure out an additional tool is needed. Perhaps "yum install foo.src" and "yum -source install foo" could return some helpful information on how people are supposed to obtain the source in a somewhat automatic way.
That seems like a bad road to go down -- should every option for every function people think a program should have return an explanation for why it actually hasn't? What I someone think "yum sourcedownload foo" would be the intuitive way? Should that also give a message? :)
But maybe a mention in the man pages is warrented, just to help people out. And this should probably go in the Yum Faq... Okay, now it is (Q14; http://wiki.linux.duke.edu/YumFaq).
Consider this scenario. A developer is running Fedora rawhide on one of his spare machines. The developer is not directly involved in the Fedora process. He just likes to keep track of the latest changes because he is a hobbyist. Fedora is also his favorite distro, so he likes to know all the latest news, so he reads mailing lists such as this one every now and then.
Now consider this. He notices that one of his favorite applications has a bug. He has two choices, fix the bug himself or file a bug report. If he chooses to file a bug report, he must first find out where the erroneous software is hosted. This probably involves a Google search or two, not so bad. Once he finds the site where the package is maintained, he must now find where to file the bug. He must now search the site for the ubiquitous Bugzilla. Now he must most likely register an account with that Bugzilla. Finally, after this whole process he must submit the bug report. Then he might track the bug by e-mail until it gets fixed (but most likely he will just forget about it and hope the maintainer gets around to fixing it). The developer could have just chosen to submit the report to Red Hat's bugzilla, but he is conscientious and knows the problem will probably be fixed sooner if he submits it directly to the project owners bug database.
Now consider the scenario where the developer can yum install --source some-package, and have it install the source along with all the dependent source packages. Then he would be able to cd to some dir where he can type make and the source will compile without issues or missing headers. Then he goes into the source dir with his favorite editor and makes a couple mods to the source. He re-compiles probably a few times and now the bug is fixed. He is no longer annoyed by the bug in his favorite app, since he typed make install and the changes automatically took effect on his machine. After maybe a day or two of running with the changes, he is sure he hasn't b0rked anything so he creates a patch and submits it to Red Hat's bugzilla. He doesn't have to worry about running around willy-nilly finding the master maintainer because he knows the Fedora maintainer already knows the lead developers and will submit the patch upstream eventually. The patch then makes its way into rawhide for more widespread testing. People on the mailing list thank the person for fixing their most hated bug. The developer feels great for helping out others who were annoyed by the same problem. The feeling is addictive and now Fedora has gained a semi-casual code contributor who most likely fixes little annoying things that the main developers couldn't be bothered with.
I, as a programmer and a Fedora hobbyist, definitely prefer the latter scenario as opposed to the former. Such an enhancement in yum would make it so much easier to hack buggy code. It would also make it easier to fix critical (or just annoying) bugs faster and perhaps deploy and test the fixes before rawhide trackers even see them. Plus, being able to fix a bug and submit a patch for it in one centralized place (RH Bugzilla) is so much more satisfying than signing up for countless Bugzilla and CVS accounts. Besides, for those who have the skills to fix the bugs instead of just reporting them, why not make it easier for these people to actually fix the bugs? Isn't this what "open source" is all about. It doesn't make sense for any distro to make it harder to install the source than it is to install binaries. Doesn't make sense at all.
This type of change would make room for more casual code contributors. Let the more dedicated Fedora/Red Hat developers worry about the semantics of getting fixes upstream. I bet even some of the more hardcore developers would soon find this functionality indispensable too.
On 11/27/05, Paul Wouters paul@cypherpunks.ca wrote:
On Sun, 27 Nov 2005, seth vidal wrote:
yum install yum-utils yumdownloader --source package
That's useful, thanks. Might this functionality ever be built into yum though?
no
That's a really good answer if you want developrs to feel that they are being taken seriously.....
Do you think there is a fundamental problem with people being able to get the sources easilly? Is yum fundamentally flawed for this? Is it too much work to put in yum?
We might appreciate decisions better if we know why they are made in a certain way.
Paul
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sun, Nov 27, 2005 at 08:17:06PM -0500, Sadda Teh wrote:
Now consider the scenario where the developer can yum install --source some-package, and have it install the source along with all the dependent source packages. Then he would be able to cd to some dir where he can type
[...]
That's a very long, tragic tale. But what in this story suggests that "yum install --source" is so much better than "yumdownloader --source"? Or even slightly better?
2005/11/28, Matthew Miller mattdm@mattdm.org:
That's a very long, tragic tale. But what in this story suggests that "yum install --source" is so much better than "yumdownloader --source"? Or even slightly better?
What if include rpm-build in yum, like apt-build, or apt-get build does? Maybe yum could become another emerge or pkg_add or so. :p
-- bbbush ^_^
On Mon, 2005-11-28 at 09:26 +0800, Yuan Yijun wrote:
2005/11/28, Matthew Miller mattdm@mattdm.org:
That's a very long, tragic tale. But what in this story suggests that "yum install --source" is so much better than "yumdownloader --source"? Or even slightly better?
What if include rpm-build in yum, like apt-build, or apt-get build does? Maybe yum could become another emerge or pkg_add or so. :p
2 items: 1. why wouldn't we make a yum-devel that handles that sort of thing so we don't have one command with 25 thousand options? 2. We wouldn't want all that building going on as root so it'd be better if that command could do it as a user.
-sv
On Sun, Nov 27, 2005 at 08:37:14PM -0500, seth vidal wrote:
What if include rpm-build in yum, like apt-build, or apt-get build does? Maybe yum could become another emerge or pkg_add or so. :p
2 items:
- why wouldn't we make a yum-devel that handles that sort of thing so
we don't have one command with 25 thousand options? 2. We wouldn't want all that building going on as root so it'd be better if that command could do it as a user.
Hmmm. I'm pretty sure the previous comment was meant as joking actually in _support_ of your position. :)
On Sun, 2005-11-27 at 20:43 -0500, Matthew Miller wrote:
On Sun, Nov 27, 2005 at 08:37:14PM -0500, seth vidal wrote:
What if include rpm-build in yum, like apt-build, or apt-get build does? Maybe yum could become another emerge or pkg_add or so. :p
2 items:
- why wouldn't we make a yum-devel that handles that sort of thing so
we don't have one command with 25 thousand options? 2. We wouldn't want all that building going on as root so it'd be better if that command could do it as a user.
Hmmm. I'm pretty sure the previous comment was meant as joking actually in _support_ of your position. :)
If someone wants to write it - more power to them.
It won't be me, though. :)
-sv
2005/11/28, seth vidal skvidal@phy.duke.edu:
On Sun, 2005-11-27 at 20:43 -0500, Matthew Miller wrote:
On Sun, Nov 27, 2005 at 08:37:14PM -0500, seth vidal wrote:
What if include rpm-build in yum, like apt-build, or apt-get build does? Maybe yum could become another emerge or pkg_add or so. :p
2 items:
- why wouldn't we make a yum-devel that handles that sort of thing so
we don't have one command with 25 thousand options? 2. We wouldn't want all that building going on as root so it'd be better if that command could do it as a user.
Hmmm. I'm pretty sure the previous comment was meant as joking actually in _support_ of your position. :)
If someone wants to write it - more power to them.
It won't be me, though. :)
-sv
not me....
Well what mock can do? I'm going to try that. If the box lacks some development package that is required by some SRPMS, could mock download and install them automatically? I think this is more annoying.
-- bbbush ^_^
2005/11/28, Yuan Yijun bbbush.yuan@gmail.com:
Well what mock can do? I'm going to try that. If the box lacks some development package that is required by some SRPMS, could mock download and install them automatically? I think this is more annoying.
Something like yum localinstall does, but for source rpms.
-- bbbush ^_^
On Mon, 28 Nov 2005, Yuan Yijun wrote:
Well what mock can do? I'm going to try that. If the box lacks some development package that is required by some SRPMS, could mock download and install them automatically? I think this is more annoying.
All I asked for was a simple way to download source package and install them.
I don't think it should do more. Running rpmbuild will show you the dependancies misisng, and those can be 'yum install'ed.
I wasn't looking for some IDE. I was looking for a method to install a source rpm without manually needing to use ftp. It seemed yum would be a good candidate for that, as people expect it in the package manager, and not in some additional package.
In fact, I'd say that rpm-build is currently missing a dependancy on yumdownloader now :)
yum is a package manager and should install packages, nothing more, but also nothing less. source packages are packages too.
Paul
On Mon, 2005-11-28 at 09:26 +0800, Yuan Yijun wrote:
What if include rpm-build in yum, like apt-build, or apt-get build does? Maybe yum could become another emerge or pkg_add or so. :p
Danger will robinson. Feature creep.
Yum downloads packages/updates from configured repositories, resolves deps, and installs those packages. Anything else is above and beyond yum. Other things can use yum libraries to accomplish that bit of task, but must provide everything else.
Now, with the new libraries that Seth is cranking out, a python script can import the yum module, do:
import yum
foo = yum.YumBase() foo.doGenericSetup()
Then you can setup all kinds of things like
foo.install(name='bar')
and
foo.update()
and when you are done lining up these yum actions, you can
foo.runTransaction()
to run it all. Yum will be very easy to tie into for doing your grander than yum actions.
(thanks seth for the examples on IRC that I copied here)
I'm thinking the "yum install --source packagename" would do the following:
1. Download src rpms and dependent libraries required for successfully rebuilding the requested source download(s) 2. Extract the the source tarball to some standard location so the developer can cd to that dir and be able to immediately do a ./configure && make without errors
I agree that having this functionality in yum may not be the best place. But, since yum already handles dependency resolution, how hard would this functionality really be to add? I just tried yumdownloader --source and all it did was download the src rpm to the current dir and nothing more. This is one step removed from going to the FTP and downloading the file. I tried yumdownloader --source yum-utils and it didn't even work. So it's clear yumdownloader does not have the functionality I desire, nor the functionality that it probably should have at a bare minimum (that is finding src equivalents of binary packages).
As for one tool doing one job well (a dogmatic mantra to begin with)... yum-utils is a 19K RPM. Is this so much code that it couldn't be integrated into yum? is someone saying the 19K of code is going to destroy yum's pristine architecture? So beyond actually adding code to yum to download the src rpm, would adding step 2. be such a conceptual leap for a tool that probably should have factored in this functionality from its inception?
On 11/27/05, Matthew Miller mattdm@mattdm.org wrote:
On Sun, Nov 27, 2005 at 08:17:06PM -0500, Sadda Teh wrote:
Now consider the scenario where the developer can yum install --source some-package, and have it install the source along with all the
dependent
source packages. Then he would be able to cd to some dir where he can
type [...]
That's a very long, tragic tale. But what in this story suggests that "yum install --source" is so much better than "yumdownloader --source"? Or even slightly better?
-- Matthew Miller mattdm@mattdm.org http://mattdm.org/ Boston University Linux ------> http://linux.bu.edu/
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sun, Nov 27, 2005 at 08:48:12PM -0500, Sadda Teh wrote:
- Download src rpms and dependent libraries required for successfully
rebuilding the requested source download(s) 2. Extract the the source tarball to some standard location so the developer can cd to that dir and be able to immediately do a ./configure && make without errors
Why do you assume that there's a source tarball at all? I think if you'll look at what's inside a lot of source RPMs, you'll find your #2 is a lot harder than you think.
#1 is also harder than it may appear at first glance. However, there's been some good work at addressing it. Check out "mock": http://fedoraproject.org/wiki/Projects/Mock
But for #1: what you want is "mock".
Okay, thanks. So I guess whether or not this functionality goes into yum or not (to me it seems to be the most intuitive place) is irrelevant. What is important is that there is a tool available that does my 2 steps. Might mock be enhanced to be that tool?
Either way, I think it would be great if the tools for src rpms were just as powerful as those for binary rpms. I understand I'm probably looking over many factors which prevent simple solutions to some of the problems mentioned, but I'm sure the problems are worth solving for the reasons I outlined in my "long, tragic tale" :).
On 11/27/05, Matthew Miller mattdm@mattdm.org wrote:
On Sun, Nov 27, 2005 at 08:48:12PM -0500, Sadda Teh wrote:
- Download src rpms and dependent libraries required for successfully
rebuilding the requested source download(s) 2. Extract the the source tarball to some standard location so the
developer
can cd to that dir and be able to immediately do a ./configure && make without errors
Why do you assume that there's a source tarball at all? I think if you'll look at what's inside a lot of source RPMs, you'll find your #2 is a lot harder than you think.
#1 is also harder than it may appear at first glance. However, there's been some good work at addressing it. Check out "mock": http://fedoraproject.org/wiki/Projects/Mock
But for #1: what you want is "mock".
-- Matthew Miller mattdm@mattdm.org http://mattdm.org/ Boston University Linux ------> http://linux.bu.edu/
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sun, Nov 27, 2005 at 09:26:41PM -0500, Sadda Teh wrote:
Okay, thanks. So I guess whether or not this functionality goes into yum or not (to me it seems to be the most intuitive place) is irrelevant. What is important is that there is a tool available that does my 2 steps. Might mock be enhanced to be that tool?
Its documentation definitely needs to be enhanced. Other than that....
On Sun, 27 Nov 2005, Sadda Teh wrote:
I'm thinking the "yum install --source packagename" would do the following:
- Download src rpms and dependent libraries required for successfully
rebuilding the requested source download(s)
That's two distinct operations, of which one requires root privileges and the other one doesn't. And both of them exist already: 1) yumdownloader --source <packagename> 2) yum-builddep <packagename> (or the just downloaded src.rpm file)
- Extract the the source tarball to some standard location so the developer
can cd to that dir and be able to immediately do a ./configure && make without errors
That's not how you work with source rpm's. With the two above steps you can however do 'rpmbuild --rebuild <src.rpm-name>'. Or like others have mentioned, use mock for the building part.
I agree that having this functionality in yum may not be the best place. But, since yum already handles dependency resolution, how hard would this functionality really be to add? I just tried yumdownloader --source and all it did was download the src rpm to the current dir and nothing more. This is one step removed from going to the FTP and downloading the file. I tried yumdownloader --source yum-utils and it didn't even work. So it's clear yumdownloader does not have the functionality I desire, nor the functionality that it probably should have at a bare minimum (that is finding src equivalents of binary packages).
"yumdownloader --source yum-utils" wont work out of the box, because the default yum setup doesn't include the SRPMS repositories for anything but initial core packages. You'll need to add a separate entry to yum.repos.d that includes extras SRPMS repo.
- Panu -
On Sun, 27 Nov 2005, Panu Matilainen wrote:
"yumdownloader --source yum-utils" wont work out of the box, because the default yum setup doesn't include the SRPMS repositories for anything but initial core packages. You'll need to add a separate entry to yum.repos.d that includes extras SRPMS repo.
That's a bug then. Either the source repo listing should come with yum, or with yumdownloader.
The whole point of this thread (to me at least) is to fix the problem of not being able to easilly installing source rpms without a need to go hunt or edit manual files.
Paul
On Mon, 28 Nov 2005, Paul Wouters wrote:
On Sun, 27 Nov 2005, Panu Matilainen wrote:
"yumdownloader --source yum-utils" wont work out of the box, because the default yum setup doesn't include the SRPMS repositories for anything but initial core packages. You'll need to add a separate entry to yum.repos.d that includes extras SRPMS repo.
That's a bug then. Either the source repo listing should come with yum, or with yumdownloader.
The whole point of this thread (to me at least) is to fix the problem of not being able to easilly installing source rpms without a need to go hunt or edit manual files.
I'm all for adding extras-src etc source repositories to default yum setup but we don't want those to be enabled by default - few people of the userbase will ever need them so having them enabled will just waste bandwidth and make yum slower. A developer who knows he needs that stuff can be reasonably expected to flip enabled = 0 -> 1 in a file or two I think :)
- Panu -
On Sun, Nov 27, 2005 at 11:55:40PM -0800, Panu Matilainen wrote:
I'm all for adding extras-src etc source repositories to default yum setup but we don't want those to be enabled by default - few people of the userbase will ever need them so having them enabled will just waste bandwidth and make yum slower. A developer who knows he needs that stuff can be reasonably expected to flip enabled = 0 -> 1 in a file or two I think :)
This does raise a good point though -- since core yum can't even deal with src.rpms, shouldn't there be an easy way to tag source rpm repo config files so yum ignores them but that they're _all_ yumdownloader --source looks at?
On Mon, 2005-11-28 at 07:46 -0500, Matthew Miller wrote:
On Sun, Nov 27, 2005 at 11:55:40PM -0800, Panu Matilainen wrote:
I'm all for adding extras-src etc source repositories to default yum setup but we don't want those to be enabled by default - few people of the userbase will ever need them so having them enabled will just waste bandwidth and make yum slower. A developer who knows he needs that stuff can be reasonably expected to flip enabled = 0 -> 1 in a file or two I think :)
This does raise a good point though -- since core yum can't even deal with src.rpms, shouldn't there be an easy way to tag source rpm repo config files so yum ignores them but that they're _all_ yumdownloader --source looks at?
we'd need another config item per repo to distinguish source-only repos from others. Yes, that's doable but is it worth it?
-sv
On Mon, Nov 28, 2005 at 08:47:34AM -0500, seth vidal wrote:
This does raise a good point though -- since core yum can't even deal with src.rpms, shouldn't there be an easy way to tag source rpm repo config files so yum ignores them but that they're _all_ yumdownloader --source looks at?
we'd need another config item per repo to distinguish source-only repos from others. Yes, that's doable but is it worth it?
Since currently, enabling source rpm repos causes yum to repeatedly do a lot of work for no reason, it seems like a pretty decent thing.
On 11/29/05, seth vidal skvidal@phy.duke.edu wrote:
we'd need another config item per repo to distinguish source-only repos from others. Yes, that's doable but is it worth it?
-sv
In the primary.xml files, there is a 'rpm:sourcerpm' tag; would that be usable at all to install srouce rpms or do you need the whole <package> with <arch>src</arch> like in core?
n0dalus.
On Tue, 2005-11-29 at 01:33 +1030, n0dalus wrote:
On 11/29/05, seth vidal skvidal@phy.duke.edu wrote:
we'd need another config item per repo to distinguish source-only repos from others. Yes, that's doable but is it worth it?
-sv
In the primary.xml files, there is a 'rpm:sourcerpm' tag; would that be usable at all to install srouce rpms or do you need the whole <package> with <arch>src</arch> like in core?
we need the whole path to the src.rpm and we need some way of distinguishing the types of repo BEFORE reading in the metadata.
-sv
On 11/28/05, seth vidal skvidal@phy.duke.edu wrote:
we need the whole path to the src.rpm and we need some way of distinguishing the types of repo BEFORE reading in the metadata.
But I have to wonder...for yumdownloader and repoquery to work efficiently it still helps to pull in metadata about the srpm repos during yum runs. Out-of-date srpm information isn't particularly useful.
If the magical mirrorlist and metadata caching makes it into the default yum configuration...how expensive does retrieving the srpm metadata become?
At the very least I would certaintly want yum makecache to cache all the enabled repos including enabled srpm information.
I personally don't think its worth trying to turn the srpm parsing off. Once I enable srpm repos, I benefit more by having the srpm information cached locally in a state that matches the rpm information. What I'm more concerned about is seeing the srpm information and the binary information come from different mirrors which are out of sync with each other.
-jef
But I have to wonder...for yumdownloader and repoquery to work efficiently it still helps to pull in metadata about the srpm repos during yum runs. Out-of-date srpm information isn't particularly useful.
why? That's like saying - in order to work efficiently it's best if firefox cache every page you've ever been to and all of those pages you've NOT been to, too.
If the magical mirrorlist and metadata caching makes it into the default yum configuration...how expensive does retrieving the srpm metadata become?
a little less than double the amount of data.
At the very least I would certaintly want yum makecache to cache all the enabled repos including enabled srpm information.
If a source repo is not enabled then it's not enabled. The only thing marking them as source would do is tell yumdownloader which repos to enable if someone passed --source to it.
I personally don't think its worth trying to turn the srpm parsing off. Once I enable srpm repos, I benefit more by having the srpm information cached locally in a state that matches the rpm information. What I'm more concerned about is seeing the srpm information and the binary information come from different mirrors which are out of sync with each other.
you're really not understanding what I'm talking about.
-sv
On Mon, 2005-11-28 at 10:19 -0500, Jeff Spaleta wrote:
On 11/28/05, seth vidal skvidal@phy.duke.edu wrote:
we need the whole path to the src.rpm and we need some way of distinguishing the types of repo BEFORE reading in the metadata.
But I have to wonder...for yumdownloader and repoquery to work efficiently it still helps to pull in metadata about the srpm repos during yum runs. Out-of-date srpm information isn't particularly useful.
If the magical mirrorlist and metadata caching makes it into the default yum configuration...how expensive does retrieving the srpm metadata become?
At the very least I would certaintly want yum makecache to cache all the enabled repos including enabled srpm information.
Both yumdownlaoder and repoquery can (and do) use a private per-user cache when running non-root so the information will be up-to-date, regardless of the system yum cache state.
- Panu -
On Mon, 2005-11-28 at 18:39 +0200, Panu Matilainen wrote:
On Mon, 2005-11-28 at 10:19 -0500, Jeff Spaleta wrote:
On 11/28/05, seth vidal skvidal@phy.duke.edu wrote:
we need the whole path to the src.rpm and we need some way of distinguishing the types of repo BEFORE reading in the metadata.
But I have to wonder...for yumdownloader and repoquery to work efficiently it still helps to pull in metadata about the srpm repos during yum runs. Out-of-date srpm information isn't particularly useful.
If the magical mirrorlist and metadata caching makes it into the default yum configuration...how expensive does retrieving the srpm metadata become?
At the very least I would certaintly want yum makecache to cache all the enabled repos including enabled srpm information.
Both yumdownlaoder and repoquery can (and do) use a private per-user cache when running non-root so the information will be up-to-date, regardless of the system yum cache state.
Erm, spoke a bit too soon, yumdownloader hadn't been fixed to use a private cache yet. It's in cvs head now though :)
- Panu -
On 11/28/05, Panu Matilainen pmatilai@laiskiainen.org wrote:
Both yumdownlaoder and repoquery can (and do) use a private per-user cache when running non-root so the information will be up-to-date, regardless of the system yum cache state.
then i relent...this time.
-jef
I hate to resurrect this thread, but here goes. A quote from Jesse Keating's most recent blog post: http://jkeating.livejournal.com/15151.html (he's speaking about FC5Test3):
"As far as infrastructure goes, this will be the first release using the new unified SRPMs layout that I have been working on. No longer will each arch have its own SRPM CD set. There will be one global source/ directory and within it there will be a SRPMS/ dir and an iso/ dir. The isos being made from the SRPMS/. The SRPMS/ directory will have repodata so that yum can be used to obtain srpms. Also I have removed the debug/ directory from the os directory where it used to live. Now the debug/ is on the same level as os and contains its own repodata and repoview content. I wanted to separate debug packages from core packages so that end users don't have to process the repo info for all the debug packages when they are using yum. So now those of you that need to debug stuff you can enable the debug repo and the srpm repo and be able to do these tasks in an easier way. This also makes it easier for mirrors to elect not to mirror debug or source content. This means we may have to munge the mirror list a bit. For this reason (and possibly others) the debug and source repos are pointed directly to download.fedora.redhat.com. I urge you to check with a local mirror to see if they are mirroring that content and if so change to use that mirror. It will lessen the load on d.f.r.c and hopefully provide packages to you in a faster manner."
Does this mean that FC5 will have the capability to do what many people in this thread thought would be a great feature of yum? That is, in FC5 will we now be able to type something along the lines of: yum install metacity.src. And then yum would download that src.rpm and all its dependencies? If so, this is great! Thanks to Jesse and whoever else cooperated to implement this feature. Just this small enhancement, I think, will encourage more developers to play around with the sources of their favorite RPMs. This feature makes it that much easier and more intuitive to get access to the source code.
To "preach" a little. The whole idea of free software means having easy access to the source. This is still something which I think no distro has really focused on making an integrated part of the distribution process. Maybe this is a start. I don't know about other packaging systems, but it seems most if not all RPM based distros have two separate worlds. One in which the binary packages exist and another where the source packages exist. Unification of these two worlds is certainly something worth striving for. Any feature that makes it easier for developers to get up and running on the given platform is worth implementing.
I guess the next logical progression of this feature would be to have a tool that "disassembles" the SRPMs so that one could cd to some standard directory and be able to fix some bugs in the source and then re-compile the changes (knowing headers, etc. of depended-on libraries are already in place so the build is successful). Probably something like this already exists?
My current perception of being able to develop software that's part of the Fedora environment means one needs intimate knowledge of RPM and its various spin off utilities. At least now it seems like a user-friendly tool like yum is going to assist in actually getting the SRPMs onto one's machine. Can Jesse or someone else expand on what this new feature really means if my impression is totally off-base?
Good day.
On Thu, 2006-02-16 at 16:36 -0500, Sadda Teh wrote:
My current perception of being able to develop software that's part of the Fedora environment means one needs intimate knowledge of RPM and its various spin off utilities. At least now it seems like a user-friendly tool like yum is going to assist in actually getting the SRPMs onto one's machine. Can Jesse or someone else expand on what this new feature really means if my impression is totally off-base?
I made a small mistake. The unified SRPMS and srpm repodata will be useful for yumdownloader, not yum itself. Yum does not and will not have the ability to grab srpms.
Hi,
El jue, 16-02-2006 a las 13:52 -0800, Jesse Keating escribió:
I made a small mistake. The unified SRPMS and srpm repodata will be useful for yumdownloader, not yum itself. Yum does not and will not have the ability to grab srpms.
yumdownloader? I hope it is what I am thinking.
You'll see, my home computer is connected to the Internet through a modem and most of the time making updates is prohibited because more often that not they are very large, so I religiously copy the packages names that needs an update, I take them to my office and wget them from a very fast connection one by one into my usb memory and finally back to my home and copy the packages in the yum cache.
Is there a way to make the downloading part of this automatic? something like yum generating all the wget commands so I can use them on a very fast connection easily instead of one by one.
I like to use the following command: whet -cb http://server/package.rpm
BTW, I am using FC4 at home and FC3 at work.
Thanks in advance,
-William
__________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam �gratis! Reg�strate ya - http://correo.yahoo.com.mx/
On Sat, 2006-02-18 at 10:03 -0500, William Lovaton wrote:
Hi,
El jue, 16-02-2006 a las 13:52 -0800, Jesse Keating escribió:
I made a small mistake. The unified SRPMS and srpm repodata will be useful for yumdownloader, not yum itself. Yum does not and will not have the ability to grab srpms.
yumdownloader? I hope it is what I am thinking.
You'll see, my home computer is connected to the Internet through a modem and most of the time making updates is prohibited because more often that not they are very large, so I religiously copy the packages names that needs an update, I take them to my office and wget them from a very fast connection one by one into my usb memory and finally back to my home and copy the packages in the yum cache.
Is there a way to make the downloading part of this automatic? something like yum generating all the wget commands so I can use them on a very fast connection easily instead of one by one.
yumdownloader has a "--urls" option that will give you the URLs to download. This could easily be scripted into a bunch of wget commands.
Paul.
El lun, 20-02-2006 a las 07:37 +0000, Paul Howarth escribió:
On Sat, 2006-02-18 at 10:03 -0500, William Lovaton wrote:
Hi,
El jue, 16-02-2006 a las 13:52 -0800, Jesse Keating escribió:
I made a small mistake. The unified SRPMS and srpm repodata will be useful for yumdownloader, not yum itself. Yum does not and will not have the ability to grab srpms.
yumdownloader? I hope it is what I am thinking.
You'll see, my home computer is connected to the Internet through a modem and most of the time making updates is prohibited because more often that not they are very large, so I religiously copy the packages names that needs an update, I take them to my office and wget them from a very fast connection one by one into my usb memory and finally back to my home and copy the packages in the yum cache.
Is there a way to make the downloading part of this automatic? something like yum generating all the wget commands so I can use them on a very fast connection easily instead of one by one.
yumdownloader has a "--urls" option that will give you the URLs to download. This could easily be scripted into a bunch of wget commands.
Paul.
Little question: is this a FC5 thing only? or I can get it for FC4 too? If so, where can I get it?
Thanks,
-William
__________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam �gratis! Reg�strate ya - http://correo.yahoo.com.mx/
William Lovaton wrote:
El lun, 20-02-2006 a las 07:37 +0000, Paul Howarth escribió:
On Sat, 2006-02-18 at 10:03 -0500, William Lovaton wrote:
Hi,
El jue, 16-02-2006 a las 13:52 -0800, Jesse Keating escribió:
I made a small mistake. The unified SRPMS and srpm repodata will be useful for yumdownloader, not yum itself. Yum does not and will not have the ability to grab srpms.
yumdownloader? I hope it is what I am thinking.
You'll see, my home computer is connected to the Internet through a modem and most of the time making updates is prohibited because more often that not they are very large, so I religiously copy the packages names that needs an update, I take them to my office and wget them from a very fast connection one by one into my usb memory and finally back to my home and copy the packages in the yum cache.
Is there a way to make the downloading part of this automatic? something like yum generating all the wget commands so I can use them on a very fast connection easily instead of one by one.
yumdownloader has a "--urls" option that will give you the URLs to download. This could easily be scripted into a bunch of wget commands.
Paul.
Little question: is this a FC5 thing only? or I can get it for FC4 too? If so, where can I get it?
yumdownloader is part of the yum-utils package, which is available in Extras for FC4.
Paul.
2006/2/16, Jesse Keating jkeating@j2solutions.net:
On Thu, 2006-02-16 at 16:36 -0500, Sadda Teh wrote:
My current perception of being able to develop software that's part of the Fedora environment means one needs intimate knowledge of RPM and its various spin off utilities. At least now it seems like a user-friendly tool like yum is going to assist in actually getting the SRPMs onto one's machine. Can Jesse or someone else expand on what this new feature really means if my impression is totally off-base?
I made a small mistake. The unified SRPMS and srpm repodata will be useful for yumdownloader, not yum itself. Yum does not and will not have the ability to grab srpms.
-- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQBD9PQ54v2HLvE71NURAmhDAJ4uIsZ2nh97H/gnpw90kp14IV13DgCePFc7 XCwQYdhqauaHLcp22tUkhOw= =46zl -----END PGP SIGNATURE-----
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
will the .repo files for the debug packages be available in the fedora release package? I agree that it should be turned off by default but still it should be available, especially to simplify debugging with end users.
regards, Rudolf Kastl
On Mon, 2006-02-20 at 10:09 +0100, Rudolf Kastl wrote:
will the .repo files for the debug packages be available in the fedora release package? I agree that it should be turned off by default but still it should be available, especially to simplify debugging with end users.
Yes -- we're probably going to go with repos that are, eg,
core core-debuginfo core-sources
And similar for extras*.
Jeremy
On Mon, Nov 28, 2005 at 08:26:34AM +0100, Paul Wouters wrote:
On Sun, 27 Nov 2005, Panu Matilainen wrote:
"yumdownloader --source yum-utils" wont work out of the box, because the default yum setup doesn't include the SRPMS repositories for anything but initial core packages. You'll need to add a separate entry to yum.repos.d that includes extras SRPMS repo.
That's a bug then. Either the source repo listing should come with yum, or with yumdownloader.
Having all src.rpms in the repodata is also adding quite some time to xml processing. So moving them into separate repos does make some sense. Also having e.g. one src.rpm repo for all arches is also good.
regards,
Florian La Roche
2005/11/28, Florian La Roche laroche@redhat.com:
On Mon, Nov 28, 2005 at 08:26:34AM +0100, Paul Wouters wrote:
On Sun, 27 Nov 2005, Panu Matilainen wrote:
"yumdownloader --source yum-utils" wont work out of the box, because the default yum setup doesn't include the SRPMS repositories for anything but initial core packages. You'll need to add a separate entry to yum.repos.d that includes extras SRPMS repo.
That's a bug then. Either the source repo listing should come with yum, or with yumdownloader.
Having all src.rpms in the repodata is also adding quite some time to xml processing. So moving them into separate repos does make some sense. Also having e.g. one src.rpm repo for all arches is also good.
regards,
Florian La Roche
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
i am just curious... whats the point of "installing" source rpms? usually one just wants to fetch em and extract em into the userspace not systemspace. actually usually packages are built using a "userbuild environment". the regular way installation of rpms work is to install em "globally" and therefor encourage the user/developer to build the stuff as "root user".
regards, Rudolf Kastl
p.s. id be happy if yumdownloader --source dosbox would work for me. it doesent see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173322
On Mon, Nov 28, 2005 at 01:36:28PM +0100, Rudolf Kastl wrote:
i am just curious... whats the point of "installing" source rpms? usually one just wants to fetch em and extract em into the userspace not systemspace.
That's installing in my book. I quite often find myself going though the "find latest version, find suitable mirror, wget srpm, rpm -i" routine when trying to track down a bug in a package.
This should definitely work from a non-root account, thus is another point against integrating this in yum directly.
2005/11/28, Ralf Ertzinger fedora@camperquake.de:
On Mon, Nov 28, 2005 at 01:36:28PM +0100, Rudolf Kastl wrote:
i am just curious... whats the point of "installing" source rpms? usually one just wants to fetch em and extract em into the userspace not systemspace.
That's installing in my book. I quite often find myself going though the "find latest version, find suitable mirror, wget srpm, rpm -i" routine when trying to track down a bug in a package.
well ok but i was always against the rpm -i bleh.src.rpm foo ;) in my eyes it just doesent make sense at all to "install" src rpms. it makes sense to extract em and ready em for build though. while its the same in some sense its not in another ;).
you got exactly the same use case as me! *grins*! how come? ;)
This should definitely work from a non-root account, thus is another point against integrating this in yum directly.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Mon, Nov 28, 2005 at 08:26:34AM +0100, Paul Wouters wrote:
"yumdownloader --source yum-utils" wont work out of the box, because the default yum setup doesn't include the SRPMS repositories for anything but initial core packages. You'll need to add a separate entry to yum.repos.d that includes extras SRPMS repo.
That's a bug then. Either the source repo listing should come with yum, or with yumdownloader.
No. It's a bug, but not in yum or yum-utils -- it's a problem with the repository config, which belongs to fedora-release.
On 11/27/05, Sadda Teh saddateh@gmail.com wrote:
I, as a programmer and a Fedora hobbyist, definitely prefer the latter scenario as opposed to the former. Such an enhancement in yum would make it so much easier to hack buggy code.
bah yumdownloader --source to get the src.rpm then use mock to build the src.rpm in a consistent build environment. is that really that hard?
-jef
devel@lists.stg.fedoraproject.org
-
Florian La Roche -
Jef Spaleta -
Jeremy Katz -
Jesse Keating -
Matthew Miller -
n0dalus -
Nicholas Miell -
Panu Matilainen -
Paul Howarth -
Paul Wouters -
Peter Gordon -
Ralf Corsepius -
Ralf Ertzinger -
Rudolf Kastl -
Sadda Teh -
seth vidal -
William Lovaton -
Yuan Yijun