Trying out Fedora 10. Points of fun:
- AVC Denial messages on a ton of stuff I do – read http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/
- Learn to use ‘yum provides’ to find things
- No terminator packages yet
- Add vga=792 to /boot/grub/menu.lst for your kernel if you don’t see pretty boot screen
Edited for ignorance..
Related posts:
#1 by shermann on December 1, 2008 - 9:55 am
Quote
Hey,
fedora could switch easily to “smart” package manager…
yum is outdated…and zypper is suse…so “smart” would be a smart move…
#2 by Richard Hughes on December 1, 2008 - 10:04 am
Quote
This is a joke, right?
#3 by Paul Mellors on December 1, 2008 - 10:06 am
Quote
It’s simple, if you don’t like it don’t use it….no need to tell everyone
#4 by Paul Mellors on December 1, 2008 - 10:09 am
Quote
No offence of course
#5 by Fedora Help on December 1, 2008 - 10:16 am
Quote
* There are plenty of ways to overcome AVC denials. This might help: http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/
* ‘yum search ccsm’ tells me that package does indeed exist for F10.
* Using ‘yum search’ isn’t the right command to find a package that provides a certain file, you use ‘yum provides’ for that. When I did ‘yum provides *bin/rpmbuild’ I get the rpm-build package as expected.
* https://bugzilla.redhat.com/show_bug.cgi?id=462173 says the terminator package is under review and should be included shortly.
And yum has nothing to do with zypper.
#6 by admin on December 1, 2008 - 10:21 am
Quote
Not a joke, just very surprised by the lack of polish that went into the simple things.
Paul: I don’t believe in security through obscurity, nor mediocrity through not talking about it
These are easy fixes (except the SELinux), I have already submitted the terminator spec file so we will see will that goes.
#7 by Paul Mellors on December 1, 2008 - 10:27 am
Quote
I must admit i do miss terminator on my fedora box at work, i use it constantly on my ubuntu laptop…..
#8 by Alex on December 1, 2008 - 10:44 am
Quote
I had a similar experience. I installed Fedora 10 recently, hoping to get better text-rendering performance with my Intel graphics chipset. Every single time I resumed from suspend, I got an AVC denial saying that SELinux had prevented NetworkManager from doing something with dhclient. In past versions, I’ve gotten AVC denials for similarly silly reasons. That’s why I think the distros need “QA Complainers” who find these things and bitch incessantly until they are fixed.
#9 by Jeff Schroeder on December 1, 2008 - 10:47 am
Quote
Yeah ubuntu’s command-not-found package is pretty genius. Fedora should look into adopting it.
Ubuntu is seriously looking at adopting Plymouth in place of usplash. It is one of the talking points for teh next UDS actually.
#10 by admin on December 1, 2008 - 10:49 am
Quote
Let me clarify that I searched for compizconfig using ‘yum search compizconfig’ and only came up with backends, I didn’t search for ccsm as I assumed it would be associated with backends it uses.
#11 by Jef Spaleta on December 1, 2008 - 12:39 pm
Quote
use yum provides instead of yum search.
It may help to read the yum manpage to learn the difference between the two yum commands
If you want to see which package provides a specific file named rpmbuild try this:
yum provides “*/rpmbuild”
or this:
yum provides “*bin/rpmbuild” to narrow it to a common bin directory
Is that the sort of functionality you were looking for?
-jef
#12 by admin on December 1, 2008 - 1:06 pm
Quote
Jef, that is what I was looking for, but from the manpage itself:
Search: “Is used to find any packages matching a string in the description, summary, packager and package name fields of an rpm. Useful for finding a package you do not know by name but know by some word related to it. “
That means if I do a ‘yum search rpmbuild’ I have a reasonable expectation to find the package that includes it.
FYI I am still running F10 on my laptop, I didn’t just blow it away and delete it, and am filing bug reports / spec files etc for things I find missing, so I am not trying to be a poisonous person, was just a bit startled by the rough edges.
#13 by Jef Spaleta on December 1, 2008 - 3:50 pm
Quote
Does it mean that? Its a deep question. And I’m not sure you have enough understanding of the underlying packaging mechanisms that are in use to know for sure if that’s a valid expectation. How yum search operates is a question for yum upstream…. Fedora is not going to change how yum search operates if yum upstream doesn’t buy into it. If you feel compelled to see yum search functionality changed, you’ll need to get into the yum development mailinglist and have the discussion there.
If you want specific Fedora packages to have better packaging text strings… you will want to file bugs against specific packages in Fedora. All yum does is parse that information. Description, summary, package name.. are all..qualitative text strings…which are filled via human judgement constrained by project policy. Text fields of finite size. None of those fields are filled via automation for any package. Packager is probably the only field that yum search checks that is primarily auto-filled in the Fedora build system. If you want more descriptive text strings for any particular package, you’ll have to submit updated text package by package. I very much doubt there is a policy which could be applied repository wide for maintainers to draw from to solve the “reasonable expectation” question with regard to being able to yum search for specific cmdline executable names. Especially when yum provides exists already and solves that problem explicitly.
Can you or anyone have a reasonable expectation that the package maintainers who control those qualitative fields will use their own best judgement to fill those finitely sized text fields with the information that you personally think is most relevant? Is it even reasonable to expect maintainers to anticipate what is appropriate qualitative information for 90% or even 50% of search needs? Do your personal search patterns qualify as representative of 90% of all users? Or are you like me, the 0.01% hyper-technical-user tail of the end-user spectrum with disproportionate influence and overly grand view of the importance of your personal work habits?
The things that the provides mechanism checks however is primarily filled via automation in most cases. Yes that can be supplemented via human judgement via specific specfile syntax, but the very large majority of the filesystem provides recorded in the rpm headers are auto-collected across the entire packageset. The rpm provides mechanism is very powerful, exactly because its not qualitative and its not relying primarily on human judgement. The yum provides command is just one way to access that information, but the rpm provides data also forms the basis of the new gst codec logic in F10.
The real question isn’t the one you’ve run into. Cmdline tools for what you want to do exist, you just were using the wrong one. The 0.01% tail of the end-user distribution has the tools it needs in yum provides. The really important question is this. Can someone find a way to expose the rpm filesystem provides via PackageKit UI so that the 90% of the end-user base across all rpm using systems can make use of this information to find the right packages to install. Naively, I would imagine that would work best by turning .desktop file syntax into rpm provides for PackageKit to interpret.
-jef
#14 by admin on December 1, 2008 - 4:08 pm
Quote
Jef,
That is a blog post on it’s own
I was just expecting that it would work like ‘apt-cache search debuild’ which does show up. It is very confusing to me why apt-get has worked since the dawn of time, and for some reason people insist on making worse solutions standard.
#15 by Jef Spaleta on December 1, 2008 - 4:31 pm
Quote
Yes, you walked in with pre-existing expectations about how apt works, applied those expectations to a completely different codebase.. and got confused when things didn’t work as expected. No different than watching an emacs users try to use vi and getting wicked confused about how to even quit out of the editor.
Your accumulated knowledge of how apt works deeply biases you and also marks you as part of the 0.01% tail population of technical elite. I could probably write a mirror of your original blog post and take what I know about yum and apply it to any other package manager and make a public judgement that the other managers have serious problems because they don’t jive with my pre-existing learned behaviour. I could probably do it with vi versus emacs too. I could also do it about the absolute stupidity of having different power grid standards in different parts of the world. Or the stupidity of driving on the left side of the road…or for that matter painting bikesheds blue when they obviously should all be green.
But what would be the point? I know that its learned behaviour..learned expectation. The tools I’ve grown accustomed to have colored my expectations for everything else I lay hands on. The difference is, I recognize that bias for what it is, and I don’t make the mistake of attributing my failure to adapt to a different design as a failure of that different design.
-jef
#16 by admin on December 1, 2008 - 4:34 pm
Quote
Jef,
Kings to you, I agree.
#17 by web123 on December 1, 2008 - 7:05 pm
Quote
Yum provide the powerfull repoquery. Example :
$ repoquery -q -a –queryformat=”*%{NAME}* : %{DESCRIPTION}\n” | grep ^* | grep -i rpm | grep -i build | sort | uniq
*buildsys-build-rpmfusion-kerneldevpkgs-current* : This is a meta-package used by the buildsystem to track the kernel-devel
*buildsys-build-rpmfusion-kerneldevpkgs-newest* : This is a meta-package used by the buildsystem to track the kernel-devel
*buildsys-build-rpmfusion* : This package contains tools and lists of recent kernels that get used when
*koji* : Koji is a system for building and tracking RPMS. The base package
*mash* : mash is a tool that queries a koji buildsystem for the latest RPMs for
*mock* : Mock takes a srpm and builds it in a chroot
*plague-builder* : The Plague builder does the actual RPM package building on slave machines.
*rpm-build* : The rpm-build package contains the scripts and executable programs
*rpmrebuild* : A tool to build an RPM file from a package that has already been installed.
manpage : http://linux.die.net/man/1/repoquery