On Mon, Feb 27 12:13:07 UTC 2012, Josh Boyer jwboyer at gmail.com wrote
>> On Mon, Feb 27, 2012 at 1:44 AM, elison.niven at gmail.com:
>> I forgot to add:
>> 8) Yum cannot use an iso image as a repo without mounting it.
>> Yast in suse allows to directly use iso images as repos.
> You also forgot to add:
> 1) A proposed alternative
I am more than happy to propose alternatives.
Alternative 1 : Use a totally different package management system : apt-get
It is mature enough. I know this is going to be rejected totally even
Alternative 2 :
Make the following changes to yum to make yum better:
1) yum should maintain status of installed packages locally. And it
should not need to fetch repository information when user tries
yum info <installed-package>
Reason to have this feature : It seems logical to have information
about an installed package locally.
2) yum is currently downloading repository information separately for each user.
It can use the same downloaded repository information for all users.
For example : root did yum install <some-package> followed by
Non root user did : yum info <same-package>.
yum will currently fetch repo information again for the non root user.
Reason to have this feature : Save time, bandwidth.
3) Show progress in "Setting up update process" or "Setting up install process".
At present, users cannot know that is it working or sleeping.
Reason to have this feature : Better user experience
4) Quit on single CTRL-C. Users expect an application to quit on
Reason to have this feature : Better user experience
5) Allow to use iso image as a repo.
baseurl=file:///path/to/iso rather than baseurl=file:///path/to/mounted/iso
Reason to have this feature : Small feature but good to have.
> 2) Patches to fix any of the issues you pointed out
I am not a yum developer at present nor am acquainted with the source.
> 3) Anything constructive at all in your ramblings.
Does the above count now as constructive?
> Seriously, if you want yum replaced with something then you need to
> show up with an
> alternate proposal, how it would work, and people willing to do that
> work. Without
> those things, this is at best going to be ignored and at works just
> turn into a huge "ME
> TOO" thread that still winds up generating no change.
Your comments on the above proposals?
I'm definitely checked out in the master branch:
[tgl@rh3 master]$ git push
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.13 KiB, done.
Total 6 (delta 3), reused 0 (delta 0)
d44dce3..2e73ff7 master -> master
[tgl@rh3 master]$ fedpkg build
Building postgresql-9.1.3-1.fc17 for f17-candidate
Created task: 3822862
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3822862
Watching tasks (this may be safely interrupted)...
3822862 build (f17-candidate, /postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free
3822862 build (f17-candidate, /postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free -> open (x86-02.phx2.fedoraproject.org)
WTF? Do I need to fix this, and if so how?
regards, tom lane
Following is the list of topics that will be discussed in the FESCo
meeting tomorrow at 18:00UTC (1:00pm EST) in #fedora-meeting on
Links to all tickets below can be found at:
= Followups =
#topic #799 Issues with maintainer responsiveness (clamav)
#topic #802 F17 Features - progress at Feature Freeze
= New business =
#topic #803 Add johannbg to provenpackager explicitly to work on
#topic #806 Request for exception for iptables and ip6tables to provide
a small init script
#topic #807 static linking exception for dmtcp's mtcp_restart
#topic #810 Clarify our position on forks
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
I don't have access to edit this so I hope someone who does will.
I've noticed with several packages lately that frequently the wrong
build flags are used or appened to the ones the cmake macro sets.
Sometimes this can happen because the main cmake configuration file
forces the type to "Release" (bad!) but not always.
I've found that adding: "-DCMAKE_RELEASE_TYPE=RelWithDebinfo" often
takes care of this.
I am sending this because, we have a lot of FTBFS packages which I have
see at least one blog griping about, I accidentally fixed something that
was blocking other work (in the sense that I didn't know that other work
that I wouldn't have to do was waiting for this problem to be solved) and
I fixed something for someone that asked for help in a roundabout way.
We are all not experts in everything and it isn't a problem to ask for
help if you are stuck on something for a package. Someone else on the
devl list (or one of the programming language specific lists) may be able
to easily solve a problem that you could spend hours on without making
a lot of progress.
For those that can help, doing so is a good idea. By removing a blocker
you let someone else do work they can do on Fedora. By showing them
the resolution, they may be able to resolve similar situations when they
see them again, including cases when other developers run across the
problem. It's nice to help your fellow contributors. Fixing things makes
Fedora better for everyone.
Fedora is a feature rich Linux distribution containing the latest advancements
in open source software and I simply love Fedora.
Why does Fedora still decide to use yum? The package management system of
Fedora is still very primitive.
Here are my reasons why yum needs to go or needs *major* changes:
1) yum's interface (command line) is non-interactive. I always fail to
understand why it is
taking so long. "Setting up update process" stays for more than 1 minute at
times! (On a fairly fast PC with high speed internet connection). Atleast it
should show the user some progress as to what it is doing.
2) Quitting by CTRL-C isn't very easy. Is it?
3) On 64-bit machines, there *always* come up some issues with i686 packages
and protected multilib versions.
4) I have used Fedora for more than 5 years, I have faced "Unable to retreive
repository information repomd.xml" for like infinite times. Yes, the error
eventually gets resolved but it still comes again and again.
5) Need for autocomplete to work properly in package name argument of command
line when pressing TAB. It is painfully slow.
6) yum requires to download repository information separately for each user.
7) yum is strangely clubbed with package-cleanup,
yum-complete-transaction and I don't know what else.
These are my ramblings about yum. I know I could have filed a few of the above
as bugs and may be help to resolve them, But someone really needs to address
the bigger issue that is yum's design philosophy rather than just solve bugs in
Rather than providing me workarounds or solutions to make it work better,
Fedora needs to recognise that yum is really a huge pain to work with.
I will share one experience I had. Yesterday I did yum --enable-repo=updates
update on Fedora 16. It gave me an error stating protected multi-lib versions
of a dozen or so packages. Running package-cleanup --clean-dupes
removed 691 packages
leaving my system crippled. It removed the entire KDE and also network manager.
Now I unable to login to GNOME shell and not able to connect to any network. I
had to take backup using recovery mode before proceeding to reinstall.
I now need to reinstall my operating system. Reason : yum screwed up.
And these are the issues only regarding to the command line yum, The
GUI front-end to yum has more issues.
I do not intend to criticise any of the developers but only suggest
that yum *really* needs major changes.
Keep up the good work.
Thanks and Best Regards,