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 http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo | |
| 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 http://cvs.fedoraproject.org/viewcvs/rpms/ | ||
| 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@59.92.44.144) 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@117.192.8.247) 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: http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo#Creating_a_blank_spec_file | ||
| Name and Version is fairly self explanatory | ||
| --> pradeepto (n=pradeept@59.184.241.24) 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 http://fedoraproject.org/wiki/PackageMaintainers/CompsXml | ||
| License is the collective license of the upstream software | ||
| More details at http://fedoraproject.org/wiki/Licensing | ||
| 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@117.192.4.95) has joined #fedora-india | ||
| _Garbage_ (n=shirish@117.199.49.85) 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@122.163.208.187) 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@59.94.142.167) has joined #fedora-india | ||
| mether | A list of them are http://fedoraproject.org/wiki/Packaging/RPMMacros | |
| 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@59.184.20.151) 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@122.169.89.15) 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/ | ||
| BUILD RPMS SOURCES SPECS SRPMS | ||
| 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 http://fedoraproject.org/wiki/Projects/Mock | ||
| 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@123.239.85.143) 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@210.212.5.85) has joined #fedora-india | ||
| mether | warning is less severe. Error you need to pay more attention | |
| <-- _Garbage_ (n=shirish@117.199.49.85) 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 http://fedoraproject.org/wiki/PackageMaintainers/Common_Rpmlint_Issues | |
| 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 | |
| s/owner/owned | ||
| * 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@218.248.47.54) 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 http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Syntax | |
| 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 | http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages 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@59.180.18.36) 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 openoffice.org and that got fixed by the Red Hat developer/maintainer | ||
| <-- mustu has quit ("http://www.mibbit.com 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 | ||
| 4 | ||
| 3 | ||
| 2 | ||
| 1 | ||
| END | ||
| chacha_chaudhry | =====XXX===== | |
Generated by irclog2html.py 2.6 by Marius Gedminas - find it at mg.pov.lt!