From Fedora Project Wiki
--> You are now talking on #fedora-india
--- Topic for #fedora-india is India | Fedora: Freedom is a Feature | Fedora 9 - Sulphur is the Greatest Thing Since Fedora 8 | India Third Largest Contributor to Fedora | Packaging101 - IRC classes by mether on 28July @1500 hours IST
Topic for #fedora-india set by sankarshan at Fri Jul 25 21:42:23 2008
mether Alright, I will start anyway. we have logs later for people to follow
Roll call folks
kushal KushalDas
mether RahulSundaram
Ankur^^ AnkurSinha
--> desu (i=desu@unaffiliated/desu) has joined #fedora-india
_pjp_ _pjp_:
kushal _pjp_, name please
--> mintos (n=mvaliyav@nat/redhat-in/x-eebdb9e05092049d) has joined #fedora-india
_pjp_ ah..Prasad
mether for source material, refer to
paragn hi all
mether paragn: hello paragn
for those who have a pristine environment and just getting started
yum install fedora-packager would setup the basic tools
paragn mether, hello
mether yum groupinstall "Development Tools" is useful too for the toolchain
There are thousands of spec files available at
Ankur^^ mether : okay.. the version that came with fedora 9 is okay? i havent been able to update
mether yep, the one with fedora 9 is okay
Ankur^^ okay..
mether In most cases, you don't need to write spec files from scratch and can reuse existing ones
--> kumar (n=kumar123@ has joined #fedora-india
mether packaging allows end users to install, remove and upgrade packages easily. This includes the ability to install dependencies automatically
debarshi Debarshi Ray
mether RPM is designed to be non interactive and cleanly separate the source from the patches
paragn sample SPEC template files can be found on your system at /etc/rpmdevtools/
mether the non interactive part means that you cannot ask questions during installation
chacha_chaudhry Rakesh Pandit
mether the idea behind that is to completely automate installations. You need to pick sane defaults while packaging upstream software and any other details should be a post configuration item
The design of pristine upstream sources + patches is to enable you to move to a newer upstream release when necessary among other things
--> Soumya (n=Soumya@ has joined #fedora-india
mether RPM can be either source or binary
a source RPM consists of a spec file and the upstream files (typically a archive such as tar.gz)
The spec file determines how the software is configured, where the files are places and generally how it should be setup
you can use the sample spec files from /etc/rpmdevtools or use the rpmdev-newspec command to create templates
#rpmdev-newspec foo.spec would create a minimalistic spec
#rpmdev-newspec python foo-python.spec will create a basic spec for packaging applications written in python
The minimalistic spec file would look like this:
Name and Version is fairly self explanatory
--> pradeepto (n=pradeept@ has joined #fedora-india
mether Release is typically a number you use to differentiate between consecutive builds of the same upstream release
for example, if the upstream release is foo-1.0
and release starts from 1
pradeepto hi
pravins pradeepto
mether your source and binary packages would say foo.1.0-1
A summary is a short one line description of the software project
Group is used to categorize RPM packages. In Fedora, we rely on a alternative method of grouping using a xml file called comps
--> sshedmak (n=sshedmak@nat/redhat-in/x-ec78ad2a3061fabb) has joined #fedora-india
mether Hence the other package management tools including yum don't rely on groups anymore.
The comps file is explained in more detail at
License is the collective license of the upstream software
More details at
The Linux kernel for example would say GPLv2
In Fedora, we are more strict about specifying the licensing so we can keep track of what is being included, any potential licensing conflicts and generally making sure that Fedora is always freely usable, modifiable redistributable. The usual free and open source rights
--> Soumya_ (n=Soumya@ has joined #fedora-india
_Garbage_ (n=shirish@ has joined #fedora-india
<-- Soumya has quit (Nick collision from services.)
mether There are main sections that are typically used in a spec file
--> graydot (n=graydot@ has joined #fedora-india
--- Soumya_ is now known as Soumya
mether %prep, %build and %install
In RPM, commonly used tasks are specified as macros to save time and avoid problems
Since upstream releases come in source archives like I said earlier, you would want to extract them first
you would run something like tar zxvf foo-0.1.tar.gz
instead of that, in spec files you can use %setup macro which does this for you
it is intelligent enough to differentiate and do the right thing whether the archive is gzipped or uses bz2 or something else.
There are many such macros we use throughout the spec files
--> nitish_mythology (i=1001@ has joined #fedora-india
mether A list of them are
In %build section you will configure the extracted source
Many of the software projects allows you enable/disable specific features or configure them in a different way
Your job as a packager will include figuring out the right configuration options to specify
The packaging guidelines in Fedora enforces or recommends certain things
including disabling static libraries whenever possible, using specific file patches etc
--> ubunturos (n=ubunturo@ has joined #fedora-india
mether s/patches/paths
The guidelines however do not and cannot cover every use case
use your common sense or ask more experienced package maintainers if you are in doubt
Also note that the packaging guidelines are living documents. They do get changes over time. Do not blindly follow them. Understand the rationale behind them and verify that they are applicable for the software project you are trying to package
--> ShadowCaptian (n=raven@ has joined #fedora-india
ShadowCaptian hi all, sorry for being late...
is the packaging discussion on yet?
mether ShadowCaptian: its alright. we will post the logs. Yes, we are in the middle of it
ShadowCaptian please continue,.. and i apologise for the interruption
mether RPM while building from source
does it within a specific build directory
you should never build RPM packages as root user
Ankur^^ can you please explain why?
mether it is easy to create simple mistakes in your spec files that can wipe out your system entirely. Upstream source cannot be naively trusted and can contain malicious or unintentional consequences
so the general recommendation is to create a special user and use that only for building packages and nothing else
in my system, that user is called build. Pick any name you want and su into it before attempting to build anything
after you create a new user, running rpmdev-setuptree will create a setup a initial environment suitable for building packages safely
ls rpmbuild/
This is the set of directories the above command creates including a configuration file called .rpmmacros
What it does is instruct rpmbuild command to use these directories while building packages. It also specifies additional configurations which you can customize.
configure scripts in software projects typically adopt to the environment you build
for example, a word processor might include a optional spell checking component and it will make use of it if it already exists on your system or silently leave it out if it is not
to avoid such problems, we recommend building your software project under a chroot. In Fedora, a project called mock allows you to do this very easily
fedora-packager metapackage that I talked about in the beginning will include mock but you can also install it separately
# yum install mock. Refer to
This ensures that build dependencies are specified correctly
so if anyone else takes your source rpm and tries to build it, the success of failure would be more obvious
The other part is called run time dependencies or what you actually need to run the software
these two are different. For example. you might need a C compiler as a build dependency but it is not a run time dependency needed to actually run the software once it is compiled
Is that clear to everyone? If you have questions, feel free to ask
A build dependency is indicated using the BuildRequires tag in the spec file and Requires specifies the run-time dependencies
After the %configure section comes the %install section
The %install section is a slightly misleading name since it doesnt actually do a installation but merely copies files into the build root
In the latest rpm release, the build root is automatically set by RPM
For older releases, we continue to specify a buildroot manually
Then we have a %files section that we specify which files are supposed to be included in the binary package
Everything RPM does is stored in a database and can be queried anytime
For example rpm -qf /usr/lib/mozilla/plugins/libtotem-basic-plugin.xpt
--> Nilesh (n=root@ has joined #fedora-india
mether results in totem-mozplugin-2.23.2-5.fc9.i386
which tells me that this particular file belongs to the totem mozilla plugin package
rpm -ql will list all the files in the package and so on
In the files section, you also indicate the permissions under which the files should be installed
You need to be very careful here since subtle errors can creep in and it is a security risk to give software more permissions than it absolutely requires
after you have build a package, you can give rpmls foo.0.1.rpm to list the files and their permissions
this allows you to quickly check verify a binary package you have just build without installing them
you can download any binary package and run rpmls to verify
<-- Ankur^^ has quit (Read error: 110 (Connection timed out))
mether we also use rpmlint which catches the most common mistakes
rpmlint however is not perfect. It doesn't catch all the errors and sometimes has false positives
rpmlint -I <warning/error> would explain what that particular warning or error means
--> rangeen (n=sherry@ has joined #fedora-india
mether warning is less severe. Error you need to pay more attention
<-- _Garbage_ (n=shirish@ has left #fedora-india ("Ex-Chat")
mether Alright. That covers the basic packaging concepts and technical details
If you have questions, shoot
sankarshan there doesn't seem to be questions
paragn more information on fixing known rpmlint issues can be found at
sankarshan do we have bots only ?
kushal /awake allbots
Soumya, you can ask if you are here
* debarshi looks up
debarshi mether: Question.
mether debarshi: shoot
(but I might then ignore you ;-) )
debarshi mether: Can you just elaborate on the %defattr macro?
What each of the 4 parts mean?
mether %defattr(<file permissions>, <user>, <group>, <directory permissions>
those are the 4 parts
the default attribute says -, root, root, -
debarshi mether: Ok. Thank you.
mether the first and the last part uses the umask and all files are owner by the user and group root unless overridden
* debarshi nods
mether Gotchas to watch out for
Don't assume # will work as expected within the spec files for macros. RPM parser will ignore your # and expand the macro anyway
this can catch you by surprise if you are not aware
if you dont want something, play safe and remove them
Never build packages as root. Preferably use mock with a special user that is only used for build rpm packages
Build root should be one of those recommended in the guidelines.
A number of rpm packages in the wild are of poor quality and do not specify a correct build root, miss dependencies and so on.
That is partially our fault for not creating good packaging guidelines earlier but a lot of the repos will also take a short cut to get the packages out there quickly
* debarshi has a question on 'requires'
mether so if you are installing or basing your spec file on existing packages, make sure you are following the guidelines
debarshi: shoot
debarshi mether: If we use scriptlets, they require the stanza to be mentioned as 'Requires (postun)'.
mether: How is it different from 'Requires' ?
mether right
RPM has hooks to run different parts at the right time
Any scriplet that you use in a spec file
is not parsed by RPM itself but escaped to your shell
a Requires(postun) makes sure the RPM runs the scriplet at the right time.
* chacha_chaudhry has question regarding 'release tag'
debarshi But %postun already specifies the script and when to run it.
So why differentiate the runtime dependencies?
Is it because...
mether I dont remember the specifics offhand, paragn?
debarshi ... if I have 'Requires(post): info', then one can uninstall 'info' after my package has been installed?
But then if someone removes a requirement for a post uninstall scriptlet, then the uninstall might be broken.
paragn if you have seen scriptlets they requires certain programs to run
mether chacha_chaudhry: shoot
paragn like for info at time of removing/upgrading your package it needs to cleanup existing info file
--> Ankur^^ (n=Ankur@ has joined #fedora-india
debarshi paragn: Ok.
paragn: So when are these 'Requires(...)' checked? When installing the package, or just before the scriptlet is to be run?
paragn look more on post*/pre* usage at
mether A number of guidelines are workarounds for bugs and misfeatures. Some of these are fixed in the later revisions but since we want to maintain compatibility for older releases (including EPEL), we continue to retain them in the spec file
chacha_chaudhry mether: what about release field for projects source with prerelease numbers (e.g r21, rc34) or alpha/beta
paragn debarshi, just before scriptlet is to be run
mether covers this
chacha_chaudhry okay
mether sometimes upstream release names differ in a insane way and only way out is to use Epoch
but try and avoid and point out the problem to upstream projects
debarshi paragn: Yes, that answers my doubt. :-)
mether openssl for example has oddball naming conventions that differ wildly between releases with no obvious rhyme or reason
chacha_chaudhry okay
mether You might want to talk to upstream first before you start packaging if the release conventions are not obvious and plan for this
debarshi httrack is another crazy upstream
mether Epoch overrides everything and is the last way out if you get struck
Also upstream projects use release numbers to convey different meaning
* debarshi has a question regarding %doc
<-- Soumya has quit (Read error: 110 (Connection timed out))
mether the classical linux model of odd versions for unstable releases is an example of this but there are others which are far less obvious
debarshi: go ahead
<-- nitish_mythology has quit ("Leaving")
debarshi mether: Does it make a difference if I mark or don't mark the man/info pages as %doc?
debarshi desu
mether It doesn't. RPM does that automatically
debarshi mether: Ok.
mether RPM has increasingly tried to be smart about figuring out the dependencies but it does get it wrong sometime and you need to override it. This isn't the case for %doc but perl packages sometimes run into these issues
Also afaik there isn't a automated way to find out run-time dependencies unlike build dependencies (which can be figured out using mock, koji etc)
The packaging committee is a whole team of people who are experts in these areas and you can post to fedora-packaging list and ask questions if you find your peers unable to explain anything
--> baali (n=baali@ has joined #fedora-india
mether Ok, unless we have more questions, I will call the end of the meeting now
debarshi mether: One last one.
mether yes
--> snehk_ (n=snehk@nat/redhat/x-d31d43fd23996de1) has joined #fedora-india
debarshi mether: Some people add the upstream's signatures as Source1. Is it recommended or useful?
mether what do you mean by signatures
do you have a example?
paragn I think he mean tarball signatures?
debarshi foo-1.0.tar.gz.asc or something like that.
mether ah ok
debarshi paragn: Yes, tarball signatures.
paragn I don't see any use of that
debarshi I forgot the correct nomenclature.
paragn: Ok. Ok.
One more query.
mether ask
debarshi Why do we keep stressing on preserving timestamps? Things like 'cp -p', INSTALL="install -p", etc..
mether paragn: this should be your favorite one I guess
paragn mether, I got that from mtasaka so it favorite of mtasaka
<-- snehk_ (n=snehk@nat/redhat/x-d31d43fd23996de1) has left #fedora-india
paragn basically we try to keep timestamps of upstream files to make sure what upstream gave in that file actually to differentiate any changes done by any daemon/ourselves
mether debarshi: it is not strictly required but it useful to identify when you pull from upstream
sandeeps may be to record when new library was installed on the system and when you remove the library to keep the library information on current Linux system
paragn so its crosscheck between upstream provided file and to check if something has modified it
debarshi Ah, ok.
mether right, this is a additional check along with md5sum's
debarshi One more question. Related to multilib.
Say I have foo.i386 and foo.x86_64, both of which install /usr/bin/foo.
How is this collision handled? I mean is it even possible? Or this is only allowed for libraries?
(I mean what are the prime targets for multilib conflicts in simple terms?)
mether Libraries are the typical targets, yes
debarshi mether: Ones which hard-code /usr/lib, isn't it?
mether RPM gives priority (in rpm terms, color) to a particular arch over another and ignores the collision
debarshi mether: Oh, ok. Ok.
mether yes, file path is what determines this particular feature/ hack afaik
debarshi So we only maintain separate copies for libraries and let others get overwiritten by priority?
mether That's the gist of it. However there are lot of oddball corner cases. I certainly don't know them all
There is a good reason, other packaging systems like .deb have ignored this till now
It is pretty hard to get right
<-- pradeepto has quit (Read error: 110 (Connection timed out))
mether We don't install multi-lib by default in yum anymore to try and avoid the problems
The last major piece of foss software and was and that got fixed by the Red Hat developer/maintainer
<-- mustu has quit (" ajax IRC Client")
mether There is still crap like browser plugins that we workaround using nspluginwrapper but in general this is a problem I hope goes away
Calling end of meeting. countdown to 5
chacha_chaudhry =====XXX=====

Generated by 2.6 by Marius Gedminas - find it at!