From Fedora Project Wiki
mNo edit summary |
m (internal link cleaning) |
||
(4 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
=== Fedora Classroom - Package Taxonomy and Techniques - Ignacio Vazquez-Abrams - Saturday, November | === Fedora Classroom - Package Taxonomy and Techniques - Ignacio Vazquez-Abrams - Saturday, November 8, 2008 === | ||
==== IRC Log of the Class ==== | ==== IRC Log of the Class ==== | ||
{| | |||
|- id="t23:00" | |||
| colspan="2" | -!- nirik changed the topic of #fedora-classroom to: Fedora Classroom - Package Taxonomy and Techniques with your teacher: ivazquez - See [[Communicate/IRC/Classroom]] for more info | |||
|| [[#t23:00|23:00]] | |||
|- id="t23:00" | |||
! style="background-color: #407a40" | Ineluctable | |||
| style="color: #407a40" | thanks stickster | |||
|| [[#t23:00|23:00]] | |||
|- id="t23:00" | |||
! style="background-color: #42427e" | stickster | |||
| style="color: #42427e" | neverho0d: It is, but you could work with another person to edit your summaries | |||
|| [[#t23:00|23:00]] | |||
|- id="t23:00" | |||
| colspan="2" | * kdn *bell rings* | |||
|| [[#t23:00|23:00]] | |||
|- id="t23:00" | |||
! style="background-color: #818144" | brunowolff | |||
| style="color: #818144" | If it isn't, then translating it could be another area to help out. | |||
|| [[#t23:00|23:00]] | |||
|- id="t23:01" | |||
! style="background-color: #854685" | neverho0d | |||
| style="color: #854685" | stickster: thank you | |||
|| [[#t23:01|23:01]] | |||
|- id="t23:01" | |||
! style="background-color: #42427e" | stickster | |||
| style="color: #42427e" | brunowolff: +1, exactly | |||
|| [[#t23:01|23:01]] | |||
|- id="t23:01" | |||
| colspan="2" | * stickster really scoots now | |||
|| [[#t23:01|23:01]] | |||
|- id="t23:01" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Hello everyone, and thank you for coming. | |||
|| [[#t23:01|23:01]] | |||
|- id="t23:01" | |||
! style="background-color: #8c4a4a" | mattia | |||
| style="color: #8c4a4a" | hi ivazquez | |||
|| [[#t23:01|23:01]] | |||
|- id="t23:01" | |||
! style="background-color: #4b904b" | Abd4llA | |||
| style="color: #4b904b" | Helloo Mr ivazquez :P | |||
|| [[#t23:01|23:01]] | |||
|- id="t23:01" | |||
! style="background-color: #854685" | neverho0d | |||
| style="color: #854685" | brunowolff: I'll be glad to contribute as much as I can | |||
|| [[#t23:01|23:01]] | |||
|- id="t23:01" | |||
! style="background-color: #4d4d93" | thomasj | |||
| style="color: #4d4d93" | helloiva | |||
|| [[#t23:01|23:01]] | |||
|- id="t23:01" | |||
! style="background-color: #4d4d93" | thomasj | |||
| style="color: #4d4d93" | ops | |||
|| [[#t23:01|23:01]] | |||
|- id="t23:01" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | You see them go by all the time in anaconda and PackageKit. | |||
|| [[#t23:01|23:01]] | |||
|- id="t23:01" | |||
! style="background-color: #97974f" | kiakli | |||
| style="color: #97974f" | hi | |||
|| [[#t23:01|23:01]] | |||
|- id="t23:02" | |||
! style="background-color: #9b519b" | cga | |||
| style="color: #9b519b" | ciao ivazquez, i'm here too ;) | |||
|| [[#t23:02|23:02]] | |||
|- id="t23:02" | |||
! style="background-color: #4d4d93" | thomasj | |||
| style="color: #4d4d93" | hello ivazquez | |||
|| [[#t23:02|23:02]] | |||
|- id="t23:02" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | libfoo-3.2-5.fc9... barprogs-5.2.6-0.cvs20081016... | |||
|| [[#t23:02|23:02]] | |||
|- id="t23:02" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | But just what is it that makes a package... | |||
|| [[#t23:02|23:02]] | |||
|- id="t23:02" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | ... a package? | |||
|| [[#t23:02|23:02]] | |||
|- id="t23:02" | |||
! style="background-color: #539e9e" | domg472 | |||
| style="color: #539e9e" | rpmbuil | |||
|| [[#t23:02|23:02]] | |||
|- id="t23:02" | |||
! style="background-color: #539e9e" | domg472 | |||
| style="color: #539e9e" | nvm | |||
|| [[#t23:02|23:02]] | |||
|- id="t23:03" | |||
! style="background-color: #818144" | brunowolff | |||
| style="color: #818144" | A spec file. | |||
|| [[#t23:03|23:03]] | |||
|- id="t23:03" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | At its simplest, a package is a set of files, and metadata about each file as well as about the entire bundle. | |||
|| [[#t23:03|23:03]] | |||
|- id="t23:03" | |||
! style="background-color: #a25555" | kdn | |||
| style="color: #a25555" | clean installs, clean uninstalls, clean upgrades? | |||
|| [[#t23:03|23:03]] | |||
|- id="t23:03" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Things like permissions, ownership, scripts executed during installation, etc. | |||
|| [[#t23:03|23:03]] | |||
|- id="t23:04" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | So let's spend some time looking at these things. | |||
|| [[#t23:04|23:04]] | |||
|- id="t23:04" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The most important thing you need to know about a package is its NEVRA. | |||
|| [[#t23:04|23:04]] | |||
|- id="t23:04" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | This stands for Name, Epoch, Version, Release, and Architecture. | |||
|| [[#t23:04|23:04]] | |||
|- id="t23:04" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | It's what determines when a package can be installed or upgraded. | |||
|| [[#t23:04|23:04]] | |||
|- id="t23:05" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The name is the part we're most familiar with. | |||
|| [[#t23:05|23:05]] | |||
|- id="t23:05" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | glibc, firefox, etc. | |||
|| [[#t23:05|23:05]] | |||
|- id="t23:05" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | It is the smallest part of a package we can use and still talk about the package itself. | |||
|| [[#t23:05|23:05]] | |||
|- id="t23:06" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The epoch, version, and release determine the "order" of packages. | |||
|| [[#t23:06|23:06]] | |||
|- id="t23:06" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | That is to say, which package is considered "newer" than others. | |||
|| [[#t23:06|23:06]] | |||
|- id="t23:07" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Normally we don't need to worry about the epoch, so we'll hold out on that one for just a moment. | |||
|| [[#t23:07|23:07]] | |||
|- id="t23:07" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Version is mostly self-explanatory. | |||
|| [[#t23:07|23:07]] | |||
|- id="t23:07" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | 2.8, 3.0.2, etc. | |||
|| [[#t23:07|23:07]] | |||
|- id="t23:07" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | When upstream releases software, they give it a version to keep it separate from all the other versions they release. | |||
|| [[#t23:07|23:07]] | |||
|- id="t23:08" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The first part of a package that we really get to handle as a distro is the release. | |||
|| [[#t23:08|23:08]] | |||
|- id="t23:08" | |||
! style="background-color: #57a657" | EvilBob | |||
| style="color: #57a657" | how should a packager deal with packaging a beta or prerelease version from upstream? | |||
|| [[#t23:08|23:08]] | |||
|- id="t23:09" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | That is actually covered in Fedora's packaging guidelines. | |||
|| [[#t23:09|23:09]] | |||
|- id="t23:09" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | I'll be happy to discuss packaging issues after. | |||
|| [[#t23:09|23:09]] | |||
|- id="t23:09" | |||
! style="background-color: #5959a9" | @nirik | |||
| style="color: #5959a9" | http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages | |||
|| [[#t23:09|23:09]] | |||
|- id="t23:09" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The release is used to distinguish one package of a specific version from another. | |||
|| [[#t23:09|23:09]] | |||
|- id="t23:10" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | So you package libfoo 3.2, and the first package gets a release of "1". | |||
|| [[#t23:10|23:10]] | |||
|- id="t23:10" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Then let's say someone notices a problem in your package, and you fix it. | |||
|| [[#t23:10|23:10]] | |||
|- id="t23:11" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | When you go to fix it, you keep the version the same (since it's still the same code from upstream), but you bump the release up to "2". | |||
|| [[#t23:11|23:11]] | |||
|- id="t23:11" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | That way people and tools realize that libfoo-3.2-2 is an update for libfoo-3.2-1. | |||
|| [[#t23:11|23:11]] | |||
|- id="t23:12" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | And when upstream releases a new version, say, libfoo 3.3, you can drop the release back down to "1". | |||
|| [[#t23:12|23:12]] | |||
|- id="t23:12" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | libfoo-3.3-1 is seen as an update to libfoo-3.2-2 since the version is higher. | |||
|| [[#t23:12|23:12]] | |||
|- id="t23:13" | |||
! style="background-color: #818144" | brunowolff | |||
| style="color: #818144" | The kernel seems to keep an increase release number even after minor releases? | |||
|| [[#t23:13|23:13]] | |||
|- id="t23:13" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | It used to. They fixed that. | |||
|| [[#t23:13|23:13]] | |||
|- id="t23:13" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The exact details involve all sorts of ugliness regarding the "base" commit. | |||
|| [[#t23:13|23:13]] | |||
|- id="t23:14" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | We can come back to that later. | |||
|| [[#t23:14|23:14]] | |||
|- id="t23:14" | |||
! style="background-color: #818144" | brunowolff | |||
| style="color: #818144" | When 2.27.5 was released it had -88 for the release number? | |||
|| [[#t23:14|23:14]] | |||
|- id="t23:14" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Now, epoch. | |||
|| [[#t23:14|23:14]] | |||
|- id="t23:14" | |||
! style="background-color: #818144" | brunowolff | |||
| style="color: #818144" | OK | |||
|| [[#t23:14|23:14]] | |||
|- id="t23:14" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The epoch is the rarest-seen and the most troublesome part of a package. | |||
|| [[#t23:14|23:14]] | |||
|- id="t23:15" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | By default it's not shown when you use rpm to query a package. | |||
|| [[#t23:15|23:15]] | |||
|- id="t23:15" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | (and we'll come back to querying after) | |||
|| [[#t23:15|23:15]] | |||
|- id="t23:15" | |||
! style="background-color: #adad5b" | zcat | |||
| style="color: #adad5b" | if you have rpmdevtools installed you can play with the version/epoch comparisons. rpmdev-vercmp libfoo-3.2-2 libfoo-3.2-1 | |||
|| [[#t23:15|23:15]] | |||
|- id="t23:16" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Additionally, when writing a spec file, you must include this invisible epoch in listing packages that you are dependent upon. | |||
|| [[#t23:16|23:16]] | |||
|- id="t23:16" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Many a packager has been bitten by omitting the epoch in this scenario. | |||
|| [[#t23:16|23:16]] | |||
|- id="t23:16" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Now, why would anyone use the epoch, given all this trouble? | |||
|| [[#t23:16|23:16]] | |||
|- id="t23:17" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The simple answer is that the version has had issues. | |||
|| [[#t23:17|23:17]] | |||
|- id="t23:18" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | For instance, going from, say, "3.2preview" to "3.2final" will be a problem, since 3.2preview actually looks newer than 3.2final. | |||
|| [[#t23:18|23:18]] | |||
|- id="t23:19" | |||
! style="background-color: #9b519b" | cga | |||
| style="color: #9b519b" | how comes? | |||
|| [[#t23:19|23:19]] | |||
|- id="t23:19" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | So what must be done is the epoch must be bumped to 1 (it is 0 by default), and everyone involved lets out a collective groan because of the issues mentioned earlier. | |||
|| [[#t23:19|23:19]] | |||
|- id="t23:19" | |||
! style="background-color: #4d4d93" | thomasj | |||
| style="color: #4d4d93" | cga, p - f | |||
|| [[#t23:19|23:19]] | |||
|- id="t23:19" | |||
! style="background-color: #b15db1" | Sid | |||
| style="color: #b15db1" | because 2.3preview comes later in an alphabetical listing than 2.3final | |||
|| [[#t23:19|23:19]] | |||
|- id="t23:19" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Strings in a VR are compared lexicographically. | |||
|| [[#t23:19|23:19]] | |||
|- id="t23:19" | |||
! style="background-color: #b15db1" | Sid | |||
| style="color: #b15db1" | 3.2 even | |||
|| [[#t23:19|23:19]] | |||
|- id="t23:19" | |||
! style="background-color: #9b519b" | cga | |||
| style="color: #9b519b" | i see thanks | |||
|| [[#t23:19|23:19]] | |||
|- id="t23:19" | |||
! style="background-color: #57a657" | EvilBob | |||
| style="color: #57a657" | cga: alphanumeric ordering | |||
|| [[#t23:19|23:19]] | |||
|- id="t23:19" | |||
! style="background-color: #9b519b" | cga | |||
| style="color: #9b519b" | fair enough | |||
|| [[#t23:19|23:19]] | |||
|- id="t23:20" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | This brings us to the fifth part, the architecture. | |||
|| [[#t23:20|23:20]] | |||
|- id="t23:20" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | You would think that this is a very small topic. | |||
|| [[#t23:20|23:20]] | |||
|- id="t23:20" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | After all, i386 goes on i386 machines, x86_64 on x86_64, and so on. | |||
|| [[#t23:20|23:20]] | |||
|- id="t23:21" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Unfortunately this is not true. | |||
|| [[#t23:21|23:21]] | |||
|- id="t23:21" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | And this is for 2 reasons. | |||
|| [[#t23:21|23:21]] | |||
|- id="t23:21" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The first is that there are architectures that are "equivalent" to each other. | |||
|| [[#t23:21|23:21]] | |||
|- id="t23:22" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | E.g., i386, i486, i586, i686, etc. | |||
|| [[#t23:22|23:22]] | |||
|- id="t23:22" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | You can only have a single package (with exceptions we'll cover later) with the same NA installed at a time. | |||
|| [[#t23:22|23:22]] | |||
|- id="t23:23" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | So you can't have libfoo.i386 installed at the same time as libfoo.i686. | |||
|| [[#t23:23|23:23]] | |||
|- id="t23:23" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The second is a little feature called "multilib". | |||
|| [[#t23:23|23:23]] | |||
|- id="t23:24" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | This allows packages from different equivalent architectures to be installed at the same time. | |||
|| [[#t23:24|23:24]] | |||
|- id="t23:24" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | It's what lets you install glibc.x86_64 and glibc.i686 on the same system. | |||
|| [[#t23:24|23:24]] | |||
|- id="t23:25" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | However, it also has its issues. | |||
|| [[#t23:25|23:25]] | |||
|- id="t23:25" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | Doesn't that increase the memory residency? | |||
|| [[#t23:25|23:25]] | |||
|- id="t23:26" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | One of the issues is when the x86_64 package and the ix86 (i386, i686, etc.) package contain the same files. | |||
|| [[#t23:26|23:26]] | |||
|- id="t23:26" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Sorry, memory residency? | |||
|| [[#t23:26|23:26]] | |||
|- id="t23:26" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | Don't shared libs take up memory? | |||
|| [[#t23:26|23:26]] | |||
|- id="t23:27" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | Sorry ignore that please don't want to distract you | |||
|| [[#t23:27|23:27]] | |||
|- id="t23:27" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Only when they're loaded. Packages on the disk take up no memory until they're requested. | |||
|| [[#t23:27|23:27]] | |||
|- id="t23:27" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Alright, same files. | |||
|| [[#t23:27|23:27]] | |||
|- id="t23:28" | |||
! style="background-color: #9b519b" | cga | |||
| style="color: #9b519b" | Discordian: see differences between application and process (ie. installed versus running) | |||
|| [[#t23:28|23:28]] | |||
|- id="t23:28" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | rpm does not have a problem with the x86_64 package and the ix86 package containing the same files, provided that the files are *exactly* the same. | |||
|| [[#t23:28|23:28]] | |||
|- id="t23:28" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Timestamp, contents, permissions, etc. | |||
|| [[#t23:28|23:28]] | |||
|- id="t23:28" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | cga: thank you | |||
|| [[#t23:28|23:28]] | |||
|- id="t23:28" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | But even this is not true. | |||
|| [[#t23:28|23:28]] | |||
|- id="t23:28" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | And this is where we get into trouble. | |||
|| [[#t23:28|23:28]] | |||
|- id="t23:29" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | If the x86_64 package and the ix86 package are installed in the same "transaction", rpm is perfectly willing to overlook differences in the files and will install both packages, with the x86_64 files overwriting the ix86 files. | |||
|| [[#t23:29|23:29]] | |||
|- id="t23:29" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | HOWEVER. | |||
|| [[#t23:29|23:29]] | |||
|- id="t23:30" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | If either one of the packages is already installed, and we try to install the other package, rpm will complain about file conflicts since they don't match. | |||
|| [[#t23:30|23:30]] | |||
|- id="t23:31" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | This sort of issue has spawned many more bug reports than are deserved. | |||
|| [[#t23:31|23:31]] | |||
|- id="t23:31" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | So, something to keep in mind when you install or build packages. | |||
|| [[#t23:31|23:31]] | |||
|- id="t23:32" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | So, now that we understand (I hope) these 5 elements, let's look at what else a package's metadata provides. | |||
|| [[#t23:32|23:32]] | |||
|- id="t23:33" | |||
! style="background-color: #5959a9" | @nirik | |||
| style="color: #5959a9" | I have a question: where does rpm store the ix86 binaries? If the x86_64 package is removed it would have to place the ix86 ones back right? | |||
|| [[#t23:33|23:33]] | |||
|- id="t23:33" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | It does not. It simply doesn't erase the files provided by the x86_64 package. | |||
|| [[#t23:33|23:33]] | |||
|- id="t23:33" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Yay multilib. | |||
|| [[#t23:33|23:33]] | |||
|- id="t23:34" | |||
! style="background-color: #5959a9" | @nirik | |||
| style="color: #5959a9" | yikes. ;( | |||
|| [[#t23:34|23:34]] | |||
|- id="t23:34" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | Does that mean you could rebuild both i386 and x64 rpms using rpmrebuild and they'd both be valid? | |||
|| [[#t23:34|23:34]] | |||
|- id="t23:35" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | I don't know. I've never looked at how rpmrebuild works. | |||
|| [[#t23:35|23:35]] | |||
|- id="t23:35" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | My impression is it just uses the rpm db to reconstruct the rpm file | |||
|| [[#t23:35|23:35]] | |||
|- id="t23:36" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | I'm glad you bring up the rpmdb. | |||
|| [[#t23:36|23:36]] | |||
|- id="t23:36" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | A package in a file has a set of metadata. | |||
|| [[#t23:36|23:36]] | |||
|- id="t23:36" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | When said package is installed, the metadata needs to be stored in order to retain information about the package. | |||
|| [[#t23:36|23:36]] | |||
|- id="t23:37" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The metadata is stored in what is called the rpmdb. | |||
|| [[#t23:37|23:37]] | |||
|- id="t23:37" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | We can query the rpmdb via "rpm -q". | |||
|| [[#t23:37|23:37]] | |||
|- id="t23:38" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | We pass it a name, and rpm will give us the metadata in a pre-programmed format. | |||
|| [[#t23:38|23:38]] | |||
|- id="t23:38" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Normally it looks like <name>-<version>-<release>. | |||
|| [[#t23:38|23:38]] | |||
|- id="t23:38" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | I'm not sure if they've added .<arch> to that recently. I believe so though. | |||
|| [[#t23:38|23:38]] | |||
|- id="t23:39" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | You can see an example by opening up a terminal and typing "rpm -q filesystem". | |||
|| [[#t23:39|23:39]] | |||
|- id="t23:39" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | That is the case on F9 yes | |||
|| [[#t23:39|23:39]] | |||
|- id="t23:39" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | If someone could provide the output from theirs please? | |||
|| [[#t23:39|23:39]] | |||
|- id="t23:40" | |||
! style="background-color: #b15db1" | Sid | |||
| style="color: #b15db1" | filesystem-2.4.13-1.fc9.i386 | |||
|| [[#t23:40|23:40]] | |||
|- id="t23:40" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Right, there we are. | |||
|| [[#t23:40|23:40]] | |||
|- id="t23:40" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The name is, of course, "filesystem". | |||
|| [[#t23:40|23:40]] | |||
|- id="t23:41" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The version is "2.4.13", the release is "1.fc9", and the arch is "i386". | |||
|| [[#t23:41|23:41]] | |||
|- id="t23:41" | |||
! style="background-color: #57a657" | EvilBob | |||
| style="color: #57a657" | [root@mediapc1 ~]# rpm -q filesystem | |||
|| [[#t23:41|23:41]] | |||
|- id="t23:41" | |||
! style="background-color: #57a657" | EvilBob | |||
| style="color: #57a657" | filesystem-2.4.13-1.fc9.i386 | |||
|| [[#t23:41|23:41]] | |||
|- id="t23:41" | |||
! style="background-color: #57a657" | EvilBob | |||
| style="color: #57a657" | grrr | |||
|| [[#t23:41|23:41]] | |||
|- id="t23:41" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Sometimes we need more or less than is provided by the default format. | |||
|| [[#t23:41|23:41]] | |||
|- id="t23:41" | |||
! style="background-color: #adad5b" | zcat | |||
| style="color: #adad5b" | ah. so showing the arch is default now? i've been adding "%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}" to ~/.rpmmacros so i didn't notice | |||
|| [[#t23:41|23:41]] | |||
|- id="t23:41" | |||
! style="background-color: #57a657" | EvilBob | |||
| style="color: #57a657" | filesystem-2.4.11-1.fc8 | |||
|| [[#t23:41|23:41]] | |||
|- id="t23:41" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | filesystem-2.4.13-1.fc9.i386 is what I have | |||
|| [[#t23:41|23:41]] | |||
|- id="t23:42" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Right, and we're get to query formats right now. | |||
|| [[#t23:42|23:42]] | |||
|- id="t23:42" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | *getting | |||
|| [[#t23:42|23:42]] | |||
|- id="t23:42" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Let's say that you have a script that verifies the version of certain packages on your system. | |||
|| [[#t23:42|23:42]] | |||
|- id="t23:42" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | You want to narrow down your focus to only the version. | |||
|| [[#t23:42|23:42]] | |||
|- id="t23:43" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Normally you'd do post-processing of the output of "rpm -q". | |||
|| [[#t23:43|23:43]] | |||
|- id="t23:43" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | But the default output can be changed, as demonstrated by zcat just above. | |||
|| [[#t23:43|23:43]] | |||
|- id="t23:43" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | you mean using awk or perl? | |||
|| [[#t23:43|23:43]] | |||
|- id="t23:44" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Correct. | |||
|| [[#t23:44|23:44]] | |||
|- id="t23:44" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | What you can do is you can pass rpm a parameter that tells it the format you want. | |||
|| [[#t23:44|23:44]] | |||
|- id="t23:44" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | cool I can see that would be useful | |||
|| [[#t23:44|23:44]] | |||
|- id="t23:44" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | This argument is "--qf", and it takes the format in a special, err, format. | |||
|| [[#t23:44|23:44]] | |||
|- id="t23:45" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Let's deal with just the version for now. | |||
|| [[#t23:45|23:45]] | |||
|- id="t23:45" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | To get the version of filesystem we run "rpm -q --qf '%{version}'". | |||
|| [[#t23:45|23:45]] | |||
|- id="t23:45" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | This will return just the value, with no fancy formatting. | |||
|| [[#t23:45|23:45]] | |||
|- id="t23:46" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Naturally if the output will be consumed by a person we'll at least want to put it on its own line. | |||
|| [[#t23:46|23:46]] | |||
|- id="t23:46" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The query format string takes several C-style escapes, including \n for a newline. | |||
|| [[#t23:46|23:46]] | |||
|- id="t23:47" | |||
! style="background-color: #b86161" | nuonguy | |||
| style="color: #b86161" | you mean rpm -q filesystem --qf '%{version}' right? | |||
|| [[#t23:47|23:47]] | |||
|- id="t23:47" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | "rpm -q --qf '%{version}\n'" will give us something that we can deal with easier. | |||
|| [[#t23:47|23:47]] | |||
|- id="t23:47" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Yes. | |||
|| [[#t23:47|23:47]] | |||
|- id="t23:47" | |||
! style="background-color: #854685" | neverho0d | |||
| style="color: #854685" | rpm -q --qf '%{version}\n' filesystem | |||
|| [[#t23:47|23:47]] | |||
|- id="t23:47" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Right. | |||
|| [[#t23:47|23:47]] | |||
|- id="t23:48" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | There are a large number of these "query tags" built into rpm. | |||
|| [[#t23:48|23:48]] | |||
|- id="t23:48" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | You can see a full list by running "rpm --querytags | less". | |||
|| [[#t23:48|23:48]] | |||
|- id="t23:48" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The query tags in the query format are not case-sensitive. | |||
|| [[#t23:48|23:48]] | |||
|- id="t23:48" | |||
! style="background-color: #854685" | neverho0d | |||
| style="color: #854685" | wow 163! | |||
|| [[#t23:48|23:48]] | |||
|- id="t23:49" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Most of them you'll never need though. | |||
|| [[#t23:49|23:49]] | |||
|- id="t23:49" | |||
! style="background-color: #62bb62" | daMaestro | |||
| style="color: #62bb62" | and shortcuts for those that don't want to type ;-) | |||
|| [[#t23:49|23:49]] | |||
|- id="t23:49" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Among the important ones are the 5 parts that we started with here: | |||
|| [[#t23:49|23:49]] | |||
|- id="t23:50" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | name, epoch, version, release, arch. | |||
|| [[#t23:50|23:50]] | |||
|- id="t23:50" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Also important is sourcerpm, which gives you the name of the component in Bugzilla to file bugs against. | |||
|| [[#t23:50|23:50]] | |||
|- id="t23:51" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | installtime is also useful. | |||
|| [[#t23:51|23:51]] | |||
|- id="t23:51" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | But there are 2 things to know about it. | |||
|| [[#t23:51|23:51]] | |||
|- id="t23:51" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | 1) It only makes sense in the rpmdb. Querying it from a package in a file makes no sense. | |||
|| [[#t23:51|23:51]] | |||
|- id="t23:51" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | And we'll get to querying a package in a file in a moment. | |||
|| [[#t23:51|23:51]] | |||
|- id="t23:52" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | 2) It gives its result as a *nix timestamp. Not exactly human-friendly. | |||
|| [[#t23:52|23:52]] | |||
|- id="t23:53" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | So "rpm -q --qf '%{name}: %{installtime}\n' filesystem", while technically correct, isn't all that useful. | |||
|| [[#t23:53|23:53]] | |||
|- id="t23:53" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Fortunately query tags support a suffix that you can add to modify them. | |||
|| [[#t23:53|23:53]] | |||
|- id="t23:54" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The suffix ":date" will convert a timestamp into a human-readable date and time. | |||
|| [[#t23:54|23:54]] | |||
|- id="t23:54" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | So with a small change we get "rpm -q --qf '%{name}: %{installtime:date}\n' filesystem", and we can see more clearly when our system was installed or upgraded. | |||
|| [[#t23:54|23:54]] | |||
|- id="t23:56" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Another query tag of interest is dsaheader. | |||
|| [[#t23:56|23:56]] | |||
|- id="t23:56" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | This tag tells us how, when, and who signed a package. | |||
|| [[#t23:56|23:56]] | |||
|- id="t23:56" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | We'll get into signing packages a bit later. | |||
|| [[#t23:56|23:56]] | |||
|- id="t23:57" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | Cool, this is good stuff | |||
|| [[#t23:57|23:57]] | |||
|- id="t23:57" | |||
! style="background-color: #9b519b" | cga | |||
| style="color: #9b519b" | night all, this is interesting but i'm falling asleep. i'll read the logs tomorrow. i find the classroom idea very interesting. kudos. | |||
|| [[#t23:57|23:57]] | |||
|- id="t23:57" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Take care. | |||
|| [[#t23:57|23:57]] | |||
|- id="t23:57" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Again, it spews a long hex string that will make our brains asplode if we try to consume it. | |||
|| [[#t23:57|23:57]] | |||
|- id="t23:57" | |||
| colspan="2" | * nirik didn't know the :date stuff. very cool. | |||
|| [[#t23:57|23:57]] | |||
|- id="t23:58" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Suffixing it with ":pgpsig" processes it and gives us a result we can use. | |||
|| [[#t23:58|23:58]] | |||
|- id="t23:58" | |||
! style="background-color: #62bb62" | daMaestro | |||
| style="color: #62bb62" | yes, i just wasted a few moments trying to pipe the unix timestamp to data -d via xargs | |||
|| [[#t23:58|23:58]] | |||
|- id="t23:58" | |||
! style="background-color: #62bb62" | daMaestro | |||
| style="color: #62bb62" | thanks. | |||
|| [[#t23:58|23:58]] | |||
|- id="t23:58" | |||
! style="background-color: #a25555" | kdn | |||
| style="color: #a25555" | Thanks to all. This was a Good Thing(tm). | |||
|| [[#t23:58|23:58]] | |||
|- id="t23:58" | |||
| colspan="2" | * delhage agrees | |||
|| [[#t23:58|23:58]] | |||
|- id="t23:58" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | rpm -q --qf '%{name}: %{dsaheader:pgpsig}\n' filesystem | |||
|| [[#t23:58|23:58]] | |||
|- id="t23:58" | |||
! style="background-color: #62bb62" | daMaestro | |||
| style="color: #62bb62" | it's not over | |||
|| [[#t23:58|23:58]] | |||
|- id="t23:58" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | I'm not going | |||
|| [[#t23:58|23:58]] | |||
|- id="t23:58" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | I'll leave it as an exercise for the reader as to whose key that is ;) | |||
|| [[#t23:58|23:58]] | |||
|- id="t23:59" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | heh | |||
|| [[#t23:59|23:59]] | |||
|- id="t23:59" | |||
! style="background-color: #818144" | brunowolff | |||
| style="color: #818144" | How well do you have to know the code to package something from upstream? | |||
|| [[#t23:59|23:59]] | |||
|- id="t23:59" | |||
| colspan="2" | * nirik notes that this is the last class scheduled today... more classess tomorrow. | |||
|| [[#t23:59|23:59]] | |||
|- id="t23:59" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Almost not at all. | |||
|| [[#t23:59|23:59]] | |||
|- id="t23:59" | |||
! style="background-color: #539e9e" | domg472 | |||
| style="color: #539e9e" | why --qf and not -qf, would that conflict? | |||
|| [[#t23:59|23:59]] | |||
|- id="t00:00" | |||
! style="background-color: #818144" | brunowolff | |||
| style="color: #818144" | So a good working relationship with upstream would be good enough? | |||
|| [[#t00:00|00:00]] | |||
|- id="t00:00" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | -qf is seen as a combination of 2 flags, -q and -f. | |||
|| [[#t00:00|00:00]] | |||
|- id="t00:00" | |||
! style="background-color: #539e9e" | domg472 | |||
| style="color: #539e9e" | i see | |||
|| [[#t00:00|00:00]] | |||
|- id="t00:00" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | -qf is which package does this file come from | |||
|| [[#t00:00|00:00]] | |||
|- id="t00:00" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | brunowolff: Not even. There are a number of instances where upstream is not even aware of it. | |||
|| [[#t00:00|00:00]] | |||
|- id="t00:00" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Okay, packages on disk. | |||
|| [[#t00:00|00:00]] | |||
|- id="t00:00" | |||
! style="background-color: #b15db1" | Sid | |||
| style="color: #b15db1" | is it possible to query packages that aren't installed? | |||
|| [[#t00:00|00:00]] | |||
|- id="t00:01" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Yes it is. | |||
|| [[#t00:01|00:01]] | |||
|- id="t00:01" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | There isn't much to say about packages on disk, other than you need to add -p to rpm. | |||
|| [[#t00:01|00:01]] | |||
|- id="t00:01" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | And of course, some tags such as installtime don't make sense. | |||
|| [[#t00:01|00:01]] | |||
|- id="t00:01" | |||
! style="background-color: #818144" | brunowolff | |||
| style="color: #818144" | Is there a good place to get info on how to package java apps? I have one I build from ant locally, but I don't know where fedora wants | |||
|| [[#t00:01|00:01]] | |||
|- id="t00:02" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | After all, a package on disk isn't considered to be installed. | |||
|| [[#t00:02|00:02]] | |||
|- id="t00:02" | |||
! style="background-color: #818144" | brunowolff | |||
| style="color: #818144" | java apps placed or if there are any particular build practices to use. | |||
|| [[#t00:02|00:02]] | |||
|- id="t00:02" | |||
! style="background-color: #854685" | neverho0d | |||
| style="color: #854685" | ivazquez: it would be helpful to explain a package breaking on docs, devel and other things.... | |||
|| [[#t00:02|00:02]] | |||
|- id="t00:02" | |||
! style="background-color: #b15db1" | Sid | |||
| style="color: #b15db1" | ok, what if the package isn't on disk but simply in the yum repo, can I then query it? | |||
|| [[#t00:02|00:02]] | |||
|- id="t00:02" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | brunowolff: Fedora has an extensive set of packaging guidelines in the wiki. | |||
|| [[#t00:02|00:02]] | |||
|- id="t00:02" | |||
! style="background-color: #b15db1" | Sid | |||
| style="color: #b15db1" | or do I at least need to download the .rpm? | |||
|| [[#t00:02|00:02]] | |||
|- id="t00:02" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Another excellent question. | |||
|| [[#t00:02|00:02]] | |||
|- id="t00:02" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | neverho0d: We'll handle that in a bit. | |||
|| [[#t00:02|00:02]] | |||
|- id="t00:03" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Packages in a repo. | |||
|| [[#t00:03|00:03]] | |||
|- id="t00:03" | |||
! style="background-color: #854685" | neverho0d | |||
| style="color: #854685" | ivazquez: ok. thnks | |||
|| [[#t00:03|00:03]] | |||
|- id="t00:03" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | yum-utils has a script, repoquery, which can be used to query packages in a repo. | |||
|| [[#t00:03|00:03]] | |||
|- id="t00:03" | |||
! style="background-color: #5959a9" | @nirik | |||
| style="color: #5959a9" | brunowolff: [[Packaging/Java]] | |||
|| [[#t00:03|00:03]] | |||
|- id="t00:04" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | It takes a subset of the query tags that rpm does, due to the fact that the repo metadata has only a small fraction of the package metadata. | |||
|| [[#t00:04|00:04]] | |||
|- id="t00:04" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Other than that it takes -q and --qf just like rpm. | |||
|| [[#t00:04|00:04]] | |||
|- id="t00:05" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Alright, I think I've chewed up enough time on my bit. Which topics did I say I'd defer? | |||
|| [[#t00:05|00:05]] | |||
|- id="t00:05" | |||
! style="background-color: #818144" | brunowolff | |||
| style="color: #818144" | nirik: Thanks that looks pretty readable. I'll see if I can make it work locally. There are other issues with packaging the app (Colossus) that I am interested in. | |||
|| [[#t00:05|00:05]] | |||
|- id="t00:05" | |||
| colspan="2" | * nirik is sad that it doesn't provide sourcerpm. ;( | |||
|| [[#t00:05|00:05]] | |||
|- id="t00:05" | |||
! style="background-color: #539e9e" | domg472 | |||
| style="color: #539e9e" | thanks | |||
|| [[#t00:05|00:05]] | |||
|- id="t00:05" | |||
! style="background-color: #539e9e" | domg472 | |||
| style="color: #539e9e" | very informative day | |||
|| [[#t00:05|00:05]] | |||
|- id="t00:06" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Package breakup. | |||
|| [[#t00:06|00:06]] | |||
|- id="t00:06" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | Thank you very much | |||
|| [[#t00:06|00:06]] | |||
|- id="t00:06" | |||
! style="background-color: #6464bf" | erinlea80 | |||
| style="color: #6464bf" | Thanks ivazquez :) Its been informative. | |||
|| [[#t00:06|00:06]] | |||
|- id="t00:06" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | I learned a lot | |||
|| [[#t00:06|00:06]] | |||
|- id="t00:06" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Not quite done yet, but I understand if you have other things to do. | |||
|| [[#t00:06|00:06]] | |||
|- id="t00:06" | |||
! style="background-color: #8c4a4a" | mattia | |||
| style="color: #8c4a4a" | thanks ivazquez | |||
|| [[#t00:06|00:06]] | |||
|- id="t00:06" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | No no I'll stay | |||
|| [[#t00:06|00:06]] | |||
|- id="t00:06" | |||
! style="background-color: #c3c366" | Bugz | |||
| style="color: #c3c366" | thanks ivazquez | |||
|| [[#t00:06|00:06]] | |||
|- id="t00:06" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Part of the metadata in a package is what "type" a file is. | |||
|| [[#t00:06|00:06]] | |||
|- id="t00:07" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | That is to say, whether it's a normal file, a configuration file, or documentation. | |||
|| [[#t00:07|00:07]] | |||
|- id="t00:08" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | or a script? | |||
|| [[#t00:08|00:08]] | |||
|- id="t00:08" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | rpm allows you to query only these specific files by passing -c or -d, but most of the query tags are at the package level and so don't apply. | |||
|| [[#t00:08|00:08]] | |||
|- id="t00:08" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Package scripts are actually stored separately. | |||
|| [[#t00:08|00:08]] | |||
|- id="t00:08" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | They're in the metadata, not the files. | |||
|| [[#t00:08|00:08]] | |||
|- id="t00:08" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | Okay I've wondered about that | |||
|| [[#t00:08|00:08]] | |||
|- id="t00:09" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | They're viewable as either any of the *prog query tags, or by passing --scripts when querying a package. | |||
|| [[#t00:09|00:09]] | |||
|- id="t00:09" | |||
! style="background-color: #539e9e" | domg472 | |||
| style="color: #539e9e" | rpm -q --scripts | |||
|| [[#t00:09|00:09]] | |||
|- id="t00:09" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | Thank you | |||
|| [[#t00:09|00:09]] | |||
|- id="t00:09" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | No, I lie. Not the *prog tags. | |||
|| [[#t00:09|00:09]] | |||
|- id="t00:10" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Those are what is used to actually run the scripts. | |||
|| [[#t00:10|00:10]] | |||
|- id="t00:10" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | The scripts themselves are in the prein, postin, preun, postun, and other related tags. | |||
|| [[#t00:10|00:10]] | |||
|- id="t00:11" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Okay, I can't seem to find what other audience topics I decided to defer. | |||
|| [[#t00:11|00:11]] | |||
|- id="t00:11" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Does anyone have any questions?] | |||
|| [[#t00:11|00:11]] | |||
|- id="t00:12" | |||
! style="background-color: #539e9e" | domg472 | |||
| style="color: #539e9e" | it was all clear except the x86 x86_64 bit but that must be my fault | |||
|| [[#t00:12|00:12]] | |||
|- id="t00:12" | |||
! style="background-color: #b86161" | nuonguy | |||
| style="color: #b86161" | is there a virtual file system like /selinux or /proc to browse the rpm database? | |||
|| [[#t00:12|00:12]] | |||
|- id="t00:12" | |||
! style="background-color: #539e9e" | domg472 | |||
| style="color: #539e9e" | ill digginto that myself | |||
|| [[#t00:12|00:12]] | |||
|- id="t00:12" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | since this is Fedora : what impact will the new version of rpm have? | |||
|| [[#t00:12|00:12]] | |||
|- id="t00:12" | |||
! style="background-color: #b86161" | nuonguy | |||
| style="color: #b86161" | domg472: +1 | |||
|| [[#t00:12|00:12]] | |||
|- id="t00:12" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | or is that unfair? | |||
|| [[#t00:12|00:12]] | |||
|- id="t00:12" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | No. The rpmdb is stored as a set of bdb or sqlite databases in /var/lib/rpm. | |||
|| [[#t00:12|00:12]] | |||
|- id="t00:13" | |||
! style="background-color: #6464bf" | erinlea80 | |||
| style="color: #6464bf" | My questions were answered up above. | |||
|| [[#t00:13|00:13]] | |||
|- id="t00:13" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Which one, rpm5? | |||
|| [[#t00:13|00:13]] | |||
|- id="t00:13" | |||
| colspan="2" | * nirik muses that someone could make a fuse-rpmdb someday... | |||
|| [[#t00:13|00:13]] | |||
|- id="t00:13" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | Yeah | |||
|| [[#t00:13|00:13]] | |||
|- id="t00:13" | |||
! style="background-color: #539e9e" | domg472 | |||
| style="color: #539e9e" | by the way nuonguy id like to hear what is your reason to contribute to fedora or oss in general? | |||
|| [[#t00:13|00:13]] | |||
|- id="t00:14" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | rpm5 is an independent project. I cannot speak for Red Hat, but it has little or no impact in Fedora as far as I can see. | |||
|| [[#t00:14|00:14]] | |||
|- id="t00:14" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | the rpm maintainers in RH could probably give you a more complete answer on that one. | |||
|| [[#t00:14|00:14]] | |||
|- id="t00:15" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | Okay I noted that F10 had flagged up a new version of rpm | |||
|| [[#t00:15|00:15]] | |||
|- id="t00:15" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | I think perhaps it's 4.x | |||
|| [[#t00:15|00:15]] | |||
|- id="t00:15" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | That would be further development in the 4.x branch. | |||
|| [[#t00:15|00:15]] | |||
|- id="t00:15" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | Yes | |||
|| [[#t00:15|00:15]] | |||
|- id="t00:15" | |||
! style="background-color: #5959a9" | @nirik | |||
| style="color: #5959a9" | yes, 4.6.0 | |||
|| [[#t00:15|00:15]] | |||
|- id="t00:15" | |||
! style="background-color: #c668c6" | sdodson | |||
| style="color: #c668c6" | F10 will use 4.6. | |||
|| [[#t00:15|00:15]] | |||
|- id="t00:15" | |||
! style="background-color: #c668c6" | sdodson | |||
| style="color: #c668c6" | Though, I believe it's been requested that newer features of 4.6 not actually be used until a later date. | |||
|| [[#t00:15|00:15]] | |||
|- id="t00:16" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | Ahhh cool | |||
|| [[#t00:16|00:16]] | |||
|- id="t00:16" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | Anyone else? | |||
|| [[#t00:16|00:16]] | |||
|- id="t00:16" | |||
! style="background-color: #5959a9" | @nirik | |||
| style="color: #5959a9" | thanks ivazquez. Great session! | |||
|| [[#t00:16|00:16]] | |||
|- id="t00:16" | |||
! style="background-color: #488888" | ivazquez | |||
| style="color: #488888" | In that case, thank you for coming, and thank you for listening. | |||
|| [[#t00:16|00:16]] | |||
|- id="t00:17" | |||
! style="background-color: #5fb4b4" | Discordian | |||
| style="color: #5fb4b4" | yes thank you very much ivazquez | |||
|| [[#t00:17|00:17]] | |||
|- id="t00:17" | |||
! style="background-color: #b86161" | nuonguy | |||
| style="color: #b86161" | domg472: when I interview candidates, I ask them if they contribute to any open source projects | |||
|| [[#t00:17|00:17]] | |||
|- id="t00:17" | |||
| colspan="2" | * erinlea80 applauds | |||
|| [[#t00:17|00:17]] | |||
|- id="t00:17" | |||
! style="background-color: #854685" | neverho0d | |||
| style="color: #854685" | ivazquez: may be one another class om spec-file building? ;) | |||
|| [[#t00:17|00:17]] | |||
|} | |||
Generated by irclog2html.py 2.7 by [mailto:marius@pov.lt Marius Gedminas] - find it at [http://mg.pov.lt/irclog2html mg.pov.lt]! | |||
[[Category:Classroom|Packaging]] | |||
[[Category:Classroom]] |
Latest revision as of 08:50, 18 September 2016
Fedora Classroom - Package Taxonomy and Techniques - Ignacio Vazquez-Abrams - Saturday, November 8, 2008
IRC Log of the Class
-!- nirik changed the topic of #fedora-classroom to: Fedora Classroom - Package Taxonomy and Techniques with your teacher: ivazquez - See Communicate/IRC/Classroom for more info | 23:00 | |
Ineluctable | thanks stickster | 23:00 |
---|---|---|
stickster | neverho0d: It is, but you could work with another person to edit your summaries | 23:00 |
* kdn *bell rings* | 23:00 | |
brunowolff | If it isn't, then translating it could be another area to help out. | 23:00 |
neverho0d | stickster: thank you | 23:01 |
stickster | brunowolff: +1, exactly | 23:01 |
* stickster really scoots now | 23:01 | |
ivazquez | Hello everyone, and thank you for coming. | 23:01 |
mattia | hi ivazquez | 23:01 |
Abd4llA | Helloo Mr ivazquez :P | 23:01 |
neverho0d | brunowolff: I'll be glad to contribute as much as I can | 23:01 |
thomasj | helloiva | 23:01 |
thomasj | ops | 23:01 |
ivazquez | You see them go by all the time in anaconda and PackageKit. | 23:01 |
kiakli | hi | 23:01 |
cga | ciao ivazquez, i'm here too ;) | 23:02 |
thomasj | hello ivazquez | 23:02 |
ivazquez | libfoo-3.2-5.fc9... barprogs-5.2.6-0.cvs20081016... | 23:02 |
ivazquez | But just what is it that makes a package... | 23:02 |
ivazquez | ... a package? | 23:02 |
domg472 | rpmbuil | 23:02 |
domg472 | nvm | 23:02 |
brunowolff | A spec file. | 23:03 |
ivazquez | At its simplest, a package is a set of files, and metadata about each file as well as about the entire bundle. | 23:03 |
kdn | clean installs, clean uninstalls, clean upgrades? | 23:03 |
ivazquez | Things like permissions, ownership, scripts executed during installation, etc. | 23:03 |
ivazquez | So let's spend some time looking at these things. | 23:04 |
ivazquez | The most important thing you need to know about a package is its NEVRA. | 23:04 |
ivazquez | This stands for Name, Epoch, Version, Release, and Architecture. | 23:04 |
ivazquez | It's what determines when a package can be installed or upgraded. | 23:04 |
ivazquez | The name is the part we're most familiar with. | 23:05 |
ivazquez | glibc, firefox, etc. | 23:05 |
ivazquez | It is the smallest part of a package we can use and still talk about the package itself. | 23:05 |
ivazquez | The epoch, version, and release determine the "order" of packages. | 23:06 |
ivazquez | That is to say, which package is considered "newer" than others. | 23:06 |
ivazquez | Normally we don't need to worry about the epoch, so we'll hold out on that one for just a moment. | 23:07 |
ivazquez | Version is mostly self-explanatory. | 23:07 |
ivazquez | 2.8, 3.0.2, etc. | 23:07 |
ivazquez | When upstream releases software, they give it a version to keep it separate from all the other versions they release. | 23:07 |
ivazquez | The first part of a package that we really get to handle as a distro is the release. | 23:08 |
EvilBob | how should a packager deal with packaging a beta or prerelease version from upstream? | 23:08 |
ivazquez | That is actually covered in Fedora's packaging guidelines. | 23:09 |
ivazquez | I'll be happy to discuss packaging issues after. | 23:09 |
@nirik | http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages | 23:09 |
ivazquez | The release is used to distinguish one package of a specific version from another. | 23:09 |
ivazquez | So you package libfoo 3.2, and the first package gets a release of "1". | 23:10 |
ivazquez | Then let's say someone notices a problem in your package, and you fix it. | 23:10 |
ivazquez | When you go to fix it, you keep the version the same (since it's still the same code from upstream), but you bump the release up to "2". | 23:11 |
ivazquez | That way people and tools realize that libfoo-3.2-2 is an update for libfoo-3.2-1. | 23:11 |
ivazquez | And when upstream releases a new version, say, libfoo 3.3, you can drop the release back down to "1". | 23:12 |
ivazquez | libfoo-3.3-1 is seen as an update to libfoo-3.2-2 since the version is higher. | 23:12 |
brunowolff | The kernel seems to keep an increase release number even after minor releases? | 23:13 |
ivazquez | It used to. They fixed that. | 23:13 |
ivazquez | The exact details involve all sorts of ugliness regarding the "base" commit. | 23:13 |
ivazquez | We can come back to that later. | 23:14 |
brunowolff | When 2.27.5 was released it had -88 for the release number? | 23:14 |
ivazquez | Now, epoch. | 23:14 |
brunowolff | OK | 23:14 |
ivazquez | The epoch is the rarest-seen and the most troublesome part of a package. | 23:14 |
ivazquez | By default it's not shown when you use rpm to query a package. | 23:15 |
ivazquez | (and we'll come back to querying after) | 23:15 |
zcat | if you have rpmdevtools installed you can play with the version/epoch comparisons. rpmdev-vercmp libfoo-3.2-2 libfoo-3.2-1 | 23:15 |
ivazquez | Additionally, when writing a spec file, you must include this invisible epoch in listing packages that you are dependent upon. | 23:16 |
ivazquez | Many a packager has been bitten by omitting the epoch in this scenario. | 23:16 |
ivazquez | Now, why would anyone use the epoch, given all this trouble? | 23:16 |
ivazquez | The simple answer is that the version has had issues. | 23:17 |
ivazquez | For instance, going from, say, "3.2preview" to "3.2final" will be a problem, since 3.2preview actually looks newer than 3.2final. | 23:18 |
cga | how comes? | 23:19 |
ivazquez | So what must be done is the epoch must be bumped to 1 (it is 0 by default), and everyone involved lets out a collective groan because of the issues mentioned earlier. | 23:19 |
thomasj | cga, p - f | 23:19 |
Sid | because 2.3preview comes later in an alphabetical listing than 2.3final | 23:19 |
ivazquez | Strings in a VR are compared lexicographically. | 23:19 |
Sid | 3.2 even | 23:19 |
cga | i see thanks | 23:19 |
EvilBob | cga: alphanumeric ordering | 23:19 |
cga | fair enough | 23:19 |
ivazquez | This brings us to the fifth part, the architecture. | 23:20 |
ivazquez | You would think that this is a very small topic. | 23:20 |
ivazquez | After all, i386 goes on i386 machines, x86_64 on x86_64, and so on. | 23:20 |
ivazquez | Unfortunately this is not true. | 23:21 |
ivazquez | And this is for 2 reasons. | 23:21 |
ivazquez | The first is that there are architectures that are "equivalent" to each other. | 23:21 |
ivazquez | E.g., i386, i486, i586, i686, etc. | 23:22 |
ivazquez | You can only have a single package (with exceptions we'll cover later) with the same NA installed at a time. | 23:22 |
ivazquez | So you can't have libfoo.i386 installed at the same time as libfoo.i686. | 23:23 |
ivazquez | The second is a little feature called "multilib". | 23:23 |
ivazquez | This allows packages from different equivalent architectures to be installed at the same time. | 23:24 |
ivazquez | It's what lets you install glibc.x86_64 and glibc.i686 on the same system. | 23:24 |
ivazquez | However, it also has its issues. | 23:25 |
Discordian | Doesn't that increase the memory residency? | 23:25 |
ivazquez | One of the issues is when the x86_64 package and the ix86 (i386, i686, etc.) package contain the same files. | 23:26 |
ivazquez | Sorry, memory residency? | 23:26 |
Discordian | Don't shared libs take up memory? | 23:26 |
Discordian | Sorry ignore that please don't want to distract you | 23:27 |
ivazquez | Only when they're loaded. Packages on the disk take up no memory until they're requested. | 23:27 |
ivazquez | Alright, same files. | 23:27 |
cga | Discordian: see differences between application and process (ie. installed versus running) | 23:28 |
ivazquez | rpm does not have a problem with the x86_64 package and the ix86 package containing the same files, provided that the files are *exactly* the same. | 23:28 |
ivazquez | Timestamp, contents, permissions, etc. | 23:28 |
Discordian | cga: thank you | 23:28 |
ivazquez | But even this is not true. | 23:28 |
ivazquez | And this is where we get into trouble. | 23:28 |
ivazquez | If the x86_64 package and the ix86 package are installed in the same "transaction", rpm is perfectly willing to overlook differences in the files and will install both packages, with the x86_64 files overwriting the ix86 files. | 23:29 |
ivazquez | HOWEVER. | 23:29 |
ivazquez | If either one of the packages is already installed, and we try to install the other package, rpm will complain about file conflicts since they don't match. | 23:30 |
ivazquez | This sort of issue has spawned many more bug reports than are deserved. | 23:31 |
ivazquez | So, something to keep in mind when you install or build packages. | 23:31 |
ivazquez | So, now that we understand (I hope) these 5 elements, let's look at what else a package's metadata provides. | 23:32 |
@nirik | I have a question: where does rpm store the ix86 binaries? If the x86_64 package is removed it would have to place the ix86 ones back right? | 23:33 |
ivazquez | It does not. It simply doesn't erase the files provided by the x86_64 package. | 23:33 |
ivazquez | Yay multilib. | 23:33 |
@nirik | yikes. ;( | 23:34 |
Discordian | Does that mean you could rebuild both i386 and x64 rpms using rpmrebuild and they'd both be valid? | 23:34 |
ivazquez | I don't know. I've never looked at how rpmrebuild works. | 23:35 |
Discordian | My impression is it just uses the rpm db to reconstruct the rpm file | 23:35 |
ivazquez | I'm glad you bring up the rpmdb. | 23:36 |
ivazquez | A package in a file has a set of metadata. | 23:36 |
ivazquez | When said package is installed, the metadata needs to be stored in order to retain information about the package. | 23:36 |
ivazquez | The metadata is stored in what is called the rpmdb. | 23:37 |
ivazquez | We can query the rpmdb via "rpm -q". | 23:37 |
ivazquez | We pass it a name, and rpm will give us the metadata in a pre-programmed format. | 23:38 |
ivazquez | Normally it looks like <name>-<version>-<release>. | 23:38 |
ivazquez | I'm not sure if they've added .<arch> to that recently. I believe so though. | 23:38 |
ivazquez | You can see an example by opening up a terminal and typing "rpm -q filesystem". | 23:39 |
Discordian | That is the case on F9 yes | 23:39 |
ivazquez | If someone could provide the output from theirs please? | 23:39 |
Sid | filesystem-2.4.13-1.fc9.i386 | 23:40 |
ivazquez | Right, there we are. | 23:40 |
ivazquez | The name is, of course, "filesystem". | 23:40 |
ivazquez | The version is "2.4.13", the release is "1.fc9", and the arch is "i386". | 23:41 |
EvilBob | [root@mediapc1 ~]# rpm -q filesystem | 23:41 |
EvilBob | filesystem-2.4.13-1.fc9.i386 | 23:41 |
EvilBob | grrr | 23:41 |
ivazquez | Sometimes we need more or less than is provided by the default format. | 23:41 |
zcat | ah. so showing the arch is default now? i've been adding "%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}" to ~/.rpmmacros so i didn't notice | 23:41 |
EvilBob | filesystem-2.4.11-1.fc8 | 23:41 |
Discordian | filesystem-2.4.13-1.fc9.i386 is what I have | 23:41 |
ivazquez | Right, and we're get to query formats right now. | 23:42 |
ivazquez | *getting | 23:42 |
ivazquez | Let's say that you have a script that verifies the version of certain packages on your system. | 23:42 |
ivazquez | You want to narrow down your focus to only the version. | 23:42 |
ivazquez | Normally you'd do post-processing of the output of "rpm -q". | 23:43 |
ivazquez | But the default output can be changed, as demonstrated by zcat just above. | 23:43 |
Discordian | you mean using awk or perl? | 23:43 |
ivazquez | Correct. | 23:44 |
ivazquez | What you can do is you can pass rpm a parameter that tells it the format you want. | 23:44 |
Discordian | cool I can see that would be useful | 23:44 |
ivazquez | This argument is "--qf", and it takes the format in a special, err, format. | 23:44 |
ivazquez | Let's deal with just the version for now. | 23:45 |
ivazquez | To get the version of filesystem we run "rpm -q --qf '%{version}'". | 23:45 |
ivazquez | This will return just the value, with no fancy formatting. | 23:45 |
ivazquez | Naturally if the output will be consumed by a person we'll at least want to put it on its own line. | 23:46 |
ivazquez | The query format string takes several C-style escapes, including \n for a newline. | 23:46 |
nuonguy | you mean rpm -q filesystem --qf '%{version}' right? | 23:47 |
ivazquez | "rpm -q --qf '%{version}\n'" will give us something that we can deal with easier. | 23:47 |
ivazquez | Yes. | 23:47 |
neverho0d | rpm -q --qf '%{version}\n' filesystem | 23:47 |
ivazquez | Right. | 23:47 |
ivazquez | There are a large number of these "query tags" built into rpm. | 23:48 |
ivazquez | You can see a full list by running "rpm --querytags | less". | 23:48 |
ivazquez | The query tags in the query format are not case-sensitive. | 23:48 |
neverho0d | wow 163! | 23:48 |
ivazquez | Most of them you'll never need though. | 23:49 |
daMaestro | and shortcuts for those that don't want to type ;-) | 23:49 |
ivazquez | Among the important ones are the 5 parts that we started with here: | 23:49 |
ivazquez | name, epoch, version, release, arch. | 23:50 |
ivazquez | Also important is sourcerpm, which gives you the name of the component in Bugzilla to file bugs against. | 23:50 |
ivazquez | installtime is also useful. | 23:51 |
ivazquez | But there are 2 things to know about it. | 23:51 |
ivazquez | 1) It only makes sense in the rpmdb. Querying it from a package in a file makes no sense. | 23:51 |
ivazquez | And we'll get to querying a package in a file in a moment. | 23:51 |
ivazquez | 2) It gives its result as a *nix timestamp. Not exactly human-friendly. | 23:52 |
ivazquez | So "rpm -q --qf '%{name}: %{installtime}\n' filesystem", while technically correct, isn't all that useful. | 23:53 |
ivazquez | Fortunately query tags support a suffix that you can add to modify them. | 23:53 |
ivazquez | The suffix ":date" will convert a timestamp into a human-readable date and time. | 23:54 |
ivazquez | So with a small change we get "rpm -q --qf '%{name}: %{installtime:date}\n' filesystem", and we can see more clearly when our system was installed or upgraded. | 23:54 |
ivazquez | Another query tag of interest is dsaheader. | 23:56 |
ivazquez | This tag tells us how, when, and who signed a package. | 23:56 |
ivazquez | We'll get into signing packages a bit later. | 23:56 |
Discordian | Cool, this is good stuff | 23:57 |
cga | night all, this is interesting but i'm falling asleep. i'll read the logs tomorrow. i find the classroom idea very interesting. kudos. | 23:57 |
ivazquez | Take care. | 23:57 |
ivazquez | Again, it spews a long hex string that will make our brains asplode if we try to consume it. | 23:57 |
* nirik didn't know the :date stuff. very cool. | 23:57 | |
ivazquez | Suffixing it with ":pgpsig" processes it and gives us a result we can use. | 23:58 |
daMaestro | yes, i just wasted a few moments trying to pipe the unix timestamp to data -d via xargs | 23:58 |
daMaestro | thanks. | 23:58 |
kdn | Thanks to all. This was a Good Thing(tm). | 23:58 |
* delhage agrees | 23:58 | |
ivazquez | rpm -q --qf '%{name}: %{dsaheader:pgpsig}\n' filesystem | 23:58 |
daMaestro | it's not over | 23:58 |
Discordian | I'm not going | 23:58 |
ivazquez | I'll leave it as an exercise for the reader as to whose key that is ;) | 23:58 |
Discordian | heh | 23:59 |
brunowolff | How well do you have to know the code to package something from upstream? | 23:59 |
* nirik notes that this is the last class scheduled today... more classess tomorrow. | 23:59 | |
ivazquez | Almost not at all. | 23:59 |
domg472 | why --qf and not -qf, would that conflict? | 23:59 |
brunowolff | So a good working relationship with upstream would be good enough? | 00:00 |
ivazquez | -qf is seen as a combination of 2 flags, -q and -f. | 00:00 |
domg472 | i see | 00:00 |
Discordian | -qf is which package does this file come from | 00:00 |
ivazquez | brunowolff: Not even. There are a number of instances where upstream is not even aware of it. | 00:00 |
ivazquez | Okay, packages on disk. | 00:00 |
Sid | is it possible to query packages that aren't installed? | 00:00 |
ivazquez | Yes it is. | 00:01 |
ivazquez | There isn't much to say about packages on disk, other than you need to add -p to rpm. | 00:01 |
ivazquez | And of course, some tags such as installtime don't make sense. | 00:01 |
brunowolff | Is there a good place to get info on how to package java apps? I have one I build from ant locally, but I don't know where fedora wants | 00:01 |
ivazquez | After all, a package on disk isn't considered to be installed. | 00:02 |
brunowolff | java apps placed or if there are any particular build practices to use. | 00:02 |
neverho0d | ivazquez: it would be helpful to explain a package breaking on docs, devel and other things.... | 00:02 |
Sid | ok, what if the package isn't on disk but simply in the yum repo, can I then query it? | 00:02 |
ivazquez | brunowolff: Fedora has an extensive set of packaging guidelines in the wiki. | 00:02 |
Sid | or do I at least need to download the .rpm? | 00:02 |
ivazquez | Another excellent question. | 00:02 |
ivazquez | neverho0d: We'll handle that in a bit. | 00:02 |
ivazquez | Packages in a repo. | 00:03 |
neverho0d | ivazquez: ok. thnks | 00:03 |
ivazquez | yum-utils has a script, repoquery, which can be used to query packages in a repo. | 00:03 |
@nirik | brunowolff: Packaging/Java | 00:03 |
ivazquez | It takes a subset of the query tags that rpm does, due to the fact that the repo metadata has only a small fraction of the package metadata. | 00:04 |
ivazquez | Other than that it takes -q and --qf just like rpm. | 00:04 |
ivazquez | Alright, I think I've chewed up enough time on my bit. Which topics did I say I'd defer? | 00:05 |
brunowolff | nirik: Thanks that looks pretty readable. I'll see if I can make it work locally. There are other issues with packaging the app (Colossus) that I am interested in. | 00:05 |
* nirik is sad that it doesn't provide sourcerpm. ;( | 00:05 | |
domg472 | thanks | 00:05 |
domg472 | very informative day | 00:05 |
ivazquez | Package breakup. | 00:06 |
Discordian | Thank you very much | 00:06 |
erinlea80 | Thanks ivazquez :) Its been informative. | 00:06 |
Discordian | I learned a lot | 00:06 |
ivazquez | Not quite done yet, but I understand if you have other things to do. | 00:06 |
mattia | thanks ivazquez | 00:06 |
Discordian | No no I'll stay | 00:06 |
Bugz | thanks ivazquez | 00:06 |
ivazquez | Part of the metadata in a package is what "type" a file is. | 00:06 |
ivazquez | That is to say, whether it's a normal file, a configuration file, or documentation. | 00:07 |
Discordian | or a script? | 00:08 |
ivazquez | rpm allows you to query only these specific files by passing -c or -d, but most of the query tags are at the package level and so don't apply. | 00:08 |
ivazquez | Package scripts are actually stored separately. | 00:08 |
ivazquez | They're in the metadata, not the files. | 00:08 |
Discordian | Okay I've wondered about that | 00:08 |
ivazquez | They're viewable as either any of the *prog query tags, or by passing --scripts when querying a package. | 00:09 |
domg472 | rpm -q --scripts | 00:09 |
Discordian | Thank you | 00:09 |
ivazquez | No, I lie. Not the *prog tags. | 00:09 |
ivazquez | Those are what is used to actually run the scripts. | 00:10 |
ivazquez | The scripts themselves are in the prein, postin, preun, postun, and other related tags. | 00:10 |
ivazquez | Okay, I can't seem to find what other audience topics I decided to defer. | 00:11 |
ivazquez | Does anyone have any questions?] | 00:11 |
domg472 | it was all clear except the x86 x86_64 bit but that must be my fault | 00:12 |
nuonguy | is there a virtual file system like /selinux or /proc to browse the rpm database? | 00:12 |
domg472 | ill digginto that myself | 00:12 |
Discordian | since this is Fedora : what impact will the new version of rpm have? | 00:12 |
nuonguy | domg472: +1 | 00:12 |
Discordian | or is that unfair? | 00:12 |
ivazquez | No. The rpmdb is stored as a set of bdb or sqlite databases in /var/lib/rpm. | 00:12 |
erinlea80 | My questions were answered up above. | 00:13 |
ivazquez | Which one, rpm5? | 00:13 |
* nirik muses that someone could make a fuse-rpmdb someday... | 00:13 | |
Discordian | Yeah | 00:13 |
domg472 | by the way nuonguy id like to hear what is your reason to contribute to fedora or oss in general? | 00:13 |
ivazquez | rpm5 is an independent project. I cannot speak for Red Hat, but it has little or no impact in Fedora as far as I can see. | 00:14 |
ivazquez | the rpm maintainers in RH could probably give you a more complete answer on that one. | 00:14 |
Discordian | Okay I noted that F10 had flagged up a new version of rpm | 00:15 |
Discordian | I think perhaps it's 4.x | 00:15 |
ivazquez | That would be further development in the 4.x branch. | 00:15 |
Discordian | Yes | 00:15 |
@nirik | yes, 4.6.0 | 00:15 |
sdodson | F10 will use 4.6. | 00:15 |
sdodson | Though, I believe it's been requested that newer features of 4.6 not actually be used until a later date. | 00:15 |
Discordian | Ahhh cool | 00:16 |
ivazquez | Anyone else? | 00:16 |
@nirik | thanks ivazquez. Great session! | 00:16 |
ivazquez | In that case, thank you for coming, and thank you for listening. | 00:16 |
Discordian | yes thank you very much ivazquez | 00:17 |
nuonguy | domg472: when I interview candidates, I ask them if they contribute to any open source projects | 00:17 |
* erinlea80 applauds | 00:17 | |
neverho0d | ivazquez: may be one another class om spec-file building? ;) | 00:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!