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 7, 2008 ===
=== Fedora Classroom - Package Taxonomy and Techniques  - Ignacio Vazquez-Abrams - Saturday, November 8, 2008 ===


==== IRC Log of the Class ====
==== IRC Log of the Class ====


<!-- The easiest way to add the log is to indent it two spaces for each line.  Keep the lines around 80 chars -->
{|
|- 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 &lt;name&gt;-&lt;version&gt;-&lt;release&gt;.
|| [[#t23:38|23:38]]
|- id="t23:38"
! style="background-color: #488888" |  ivazquez
| style="color: #488888" | I'm not sure if they've added .&lt;arch&gt; 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!