packaging August 2006

packaging@lists.fedoraproject.org

35 participants
40 discussions

Mail voting on kmdl adoption
by Axel Thimm 24 Aug '06

24 Aug '06

Hi, I suggest to vote through email about replacing the current kernel scheme with the kmdl or similar scheme. a) kernel module scheme needs uname-r-in-name b) kernel module scheme needs one-specfile approach (for both usreland and kernel modules) c) kernel module scheme needs to be kernel agnostic (both version *and* flavour) d) support for coinstallation of kmdls should be pushed into FC6 asap (working plugin has already been submitted here and tested be ATrpms users). Requires a positive vote on a-c) e) Adoption of kmdl interface scheme as used at ATrpms and outlined on http://fedoraproject.org/wiki/AxelThimm/kmdls. Requires a positive vote on a-d) f) Assignment to kmdl-task force to integrate kmdl support into the buildsystems used by Fedora (myself volunteering). Requires a positive vote on a-e) g) Allow kmdl package submissions to Fedora Core/Extras. Requires a positive vote on a-f) Without voting, but dependent on vote results: Assist in GFS kmdl packaging (altready done at FC4 times, needs to resurface). -- Axel.Thimm at ATrpms.net

9 64

Packaging/Guidelines - Usage of %{optflags}
by Till Maas 24 Aug '06

24 Aug '06

Hiyas, at this time the Packaging-Guidelines do not mention whether or not %{optflags} should / must be used. They are used everytime %configure is executed, but there are also packages that do not have a ./configure script and for this reason would not use the %{optflags}. The flags in %{optflags} contain not only optimization but also security flags. For this reason I suggest that the Guidelines state that they have to be used. This will also help new contributors to know about this. I already mentioned this in fedora-extras-list, but without much feedback, but this may be the better mailinglist: https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00178.html Greetings, Till

4 10

GConf snippets suggestion
by Yanko Kaneti 23 Aug '06

23 Aug '06

Hi, Since the wiki doesn't allow useful collaboration on immutable pages, here is my suggestion for the gconf schema installation snippet in the form of a patch. It tries to emphasize the proper (IMHO) --disable-schemas-install method of disabling schemas installation on the build host vs the prevalent GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL hack (again IMHO) Regards Yanko --- ScriptletSnippets 2006-08-20 09:04:41.000000000 +0300 +++ ScriptletSnippets.gconf 2006-08-20 09:29:51.000000000 +0300 @@ -148,6 +148,12 @@ Here's the first part: {{{ +%build +%configure --disable-schemas-install +... +}}} +In the cases where the package doesn't use autotools or doesnt support the --disable-schemas-install configure flag we instuct gconftool to ignore schema installation commands by setting the GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL environment variable +{{{ %install rm -rf $RPM_BUILD_ROOT export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1

3 4

Absolute symlinks
by Jason L Tibbitts III 23 Aug '06

23 Aug '06

rpmlint spits symlink-should-be-relative warnings when it sees an absolute symlink, and generally folks have fixed things up when presented with the warning. But now I've hit a review where the packager thinks an absolute symlink is appropriate and I'm not sure whether it's really an issue. The guidelines are silent on the subject; the only mention I see of it is in the mono guidelines, which say: ---- Mono installs binaries in /usr/lib/<package>/bin with symlinks back to /usr/bin. rpmlint is not happy with this and generates an error (which is the correct behaviour). ---- That statement is somewhat confusing; is generating the error correct behavior? Is the symlink supposed to be fixed up or not? And does this apply in general to non-mono packages? - J<

6 17

Guidelines for packaging PHP
by Remi Collet 21 Aug '06

21 Aug '06

Hello, I'm back from a few holidays weeks I saw that this Guidelines is no more in draft state, but i don't see anything about the approvement on the list. Can you tell me if it is ok to push the RPM witch are ready on the CVS and to run the build ? Remi.

2 1

rpm -i, "missing" file conflicts and brokenness with kmods
by Axel Thimm 19 Aug '06

19 Aug '06

In the session today it was stated that rpm -i on packages of the same name does not check file conflicts. Since many people reported that this was the case I thought I missed the latest in rpm bug regression. But that's not the case, at least not on FC5: Cut and paste the two almost identical specfiles at the end of this mail and rpmbuild -bb them. You will get test-1-1.i386.rpm test-2-1.i386.rpm Both containing just /tmp/delmex with contents "XXX" and "YYY". Now try: | # rpm -ihv test-1-1.i386.rpm | Preparing... ########################################### [100%] | 1:test ########################################### [100%] | # rpm -Vp test-2-1.i386.rpm | ..5....TC /tmp/delmex | # rpm -ihv test-2-1.i386.rpm | Preparing... ########################################### [100%] | file /tmp/delmex from install of test-2-1 conflicts with file from package test-1-1 So rpm is not to blame it properly catches the file conflict. Now why do other people claim otherwise, and does it make any difference in the context we we discussing it? It may seem to "work" for other people because: a) either the contents of the test packages they tried were identical, e.g. rpm checks the md5sum of the files, it does not care about package names when it checks for file conflicts, b) or (according to a report from Thorsten) it may be yum that effectively uses rpm -i --replacefiles on the transaction. A yum expert could confirm the latter or not. at least it looks like Thorsten only used yum for testing and not rpm -i. Does it matter at all? In the scope of the discussion not really, it is probably making things worse. The file conflict situation only comes up when some depsolver, be it a human or yum/etc. decides to coinstall a package not meant for coinstallation. In this scope it is for example a release bump in a module for the same kernel. Accidentially using rpm -i on it would - either create the file conflict, in that sense the file conflict is a *guardian institution* - or if the --replacefiles flag is turned on, *WILL OVERWRITE* the old module, maybe even just partially, since the new module package may have a different set of ko files. Even funnier effects may happen if the now overwritten old module still in the rpmdb is tried to be removed. But we're already in a broken state, so who cares whether it can be worse. In a nutshell: o rpm -i behaves properly with file conflicts o yum may for some reason turn of file conflict checking o The file conflict situation is actually WELCOME, as it is a SAFETY precaution to not messing up thing (either by hand or automatically) And this has absolutely nothing to do with whether rpm -i can be applied to kmods, because 1) obviously rpm -i wasn't tested, or wasn't tested with differing contents in the rpm 2) rpm -i SHOULD not be used on kmods when a kmod is already installed for this kernel. 3) If you still go ahead and use rpm -i on a kmod while a kmod is already installed you get the file conflict as stated. 4) If you do the same with yum the new kmod overwrites the old one w/o any warning The desired operation that the kmod should do is only possible in the fedorakmod.py code: Don't touch kmods of other kernels, and upgrade kmods of the target kernel. Still: USAGE OF RPM CLI (-U/-i) IS NOT WORKING WITH KMOD And for all the non-believing Thomases (as in Thomas the evangelist) out there, the everlasting example wrapped as a RHCE question to make it more interesting: kernel-2.6.17 has kmod-foo-1.2.3_2.6.17 installed kernel-2.6.18 has kmod-foo-1.2.3_2.6.18 installed kmod-foo-6.6.6_2.6.18 for kernel 2.6.18 appears. How do you install it in the system above with a single rpm call (e.g. w/o removing the modules before reinstalling them) and w/o disrupting the old kernel's foo support? a) rpm -i b) rpm -U c) not at all Usage of rpm -i/rpm -U on kmod scheme is broken, end of story. I'm still shocked it suddenly was defined working a couple hours earlier today. ======================================================================= test.spec ========= Summary: test Name: test Version: 1 Release: 1 License: l Group: g BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root %description x %install mkdir -p %{buildroot}/tmp echo XXX > %{buildroot}/tmp/delmex %files %defattr(-,root,root,-) /tmp/delmex test2.spec ========== Summary: test Name: test Version: 2 Release: 1 License: l Group: g BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root %description x %install mkdir -p %{buildroot}/tmp echo YYY > %{buildroot}/tmp/delmex %files %defattr(-,root,root,-) /tmp/delmex -- Axel.Thimm at ATrpms.net

7 11

kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file
by Thorsten Leemhuis 19 Aug '06

19 Aug '06

Hi all! There are ways to many things to discuss with the current proposed schemes for packaging kernel-modules. That's why I'd like to break it up into pieces and give some details of the different implementation details. I choose to start with the "One specfile approach vs. splitted spec files" discussion because that's a bit easier to discuss then the "uname -r" stuff where even I'm still unsure how to proceed. Axel, could you please take a look at this? Did I miss anything (I surely did)? I tried to concentrate on the technical details. == One specfile approach vs. splitted spec file == Mainly a matter of taste. Some prefer the one specfile approach that's used by kmdls, other the slitted approach used by kmods. The differences: * debuginfo packages for kmdls won't get created with the automatic stuff that rpm normally uses; a script/macro that is mainly an enhanced copy of the stuff that's used by rpm currently handles that (see https://www.redhat.com/archives/fedora-packaging/2006-August/msg00053.html); that could be easily integrated into the standard macros shipped by FC / RHEL * the one-specfile approach needs some sort of mechanism to make sure that * the userland part normally isn't build for i586 and i686 because that's normally unneeded * the kernel-modules can't be build for i386 because there is no i386 kernel in FC) This is realized by %if %else %endif constructs in the spec file with the "kmdl_userland" define (see http://fedoraproject.org/wiki/AxelThimm/kmdls for details), that needs to be set by the buildsys when rpmbuild is called to build stuff * the buildsys must queue the rebuild of a kmdl srpm multiple times to get modules for all kernel flavours build in the kmdl case -- the kmods scheme can build all in one step. The variants and the kernel-version are currently hardcoded in the kmod standard because the Extras buildsys doesn't support passing the variants and the kernel version to rpmbuild call yet. Axel says that the kmod scheme is not "kernel {version,flavor} agnostic" due to this hardcoding. But this hardcoding currently allow us to build the kmods without other changes in the buildsys; kmdls can't get build without special support in the buildsys due to the needed "rebuild one srpm multiple times" * the kmod standard has the disadvantage that there are multiple srpms (e.g. one for kernel 2157 and one for kernel 2174). But this way we make sure that the Note: There is a really big area where parts/ideas of one approach could be moved over to the other and the other way around. E.g. kmods could get rid of the "kversion" in "%{RELEASE}" of the SRPMS and create the debuginfo packages manually just like kmdls do -- that would solve the "multiple SRPMS" problem. kmdls also could hardcode the kversion and kflavor stuff and use loops just like kmods -- then they would be buildable with the current buildsys.

3 19

Complaints about censoring and kmdl IRC session (resend)
by Axel Thimm 19 Aug '06

19 Aug '06

Hi, IMHO the IRC session today was a pure catastrophe. Some - especially people not following the discussion closely - were given the wrong picture and even accused me of being arrogant and what not. I'd like to file in my view, since the IRC session turned that badly. Upon request I compiled a tabular list of pros and cons of kmods vs kmdls derived from the longer writeup in the wiki. I've added all points mentioned even the ones I personally do not pay that much importance on and more importantly also these points that my proposal isn't good at including negative personal ratings for kmdls! I considered this a necessity out of fairness to everyone's contributions. W/o notice someone changed that list in a way I consider heavily censoring and very biased. I complained to him in PM, but his spam filter ate my mail and I didn't get a reply before the session (or by now either FWIW). In any case at the end of this mail I summarize the main changes [3]. Of course that new list wasn't really what I would consider a neutral, unbiased approach. There were many errors either accidentially or due to different understanding [1] which by happenstance *all* were turning against kmdls, even typos and cut&paste errors. Also important items were scratched (not the rating, but features and comparisons). Later in the session it was told that the omitted items were dumped because they were considered irrelevant, something which IMHO the people in the session should be allowed to judge for themselves. When the first difference was brought on discussion - namely that rpm -i supposedly works with kmod - I objected and gave examples why this is not the case. Independent of whether I were right or wrong [2], the following "definition of rpm -i works for kmods" was topping the censoring by itself. I can understand that people are not as deep into kernel modules as others, and that therefore some issues may look different. But shouldn't these people be open to discussion in case they are missing something (which in this case they are)? Or is this just a fake discussion where the end result is already in stone and we're just trying to justify it? ATM I really disappointed as to how things evolve. I've put lots of efforts and sweat over the last weeks into this with the target to fix something broken for the benefits of all and I don't consider this the proper reaction. Please note that I'm very far from escalating this. I wrote this mail with very careful wording, omitting on purpose all names and refraining from any direct accusations, even though I'm extremely alergic to censoring and misquoting in general. And I didn't reply on personal insults either to avoid any flaming. To get to the positive side: At least it was discussed at all (or an attempt was made) and I'd like to thank all for their participation and patience. ===================================================================== [1] I use "different" as a very neutral wording of what I personally consider "wrong". [2] IMHO I was and am correct in the statement that the kmod scheme can neither be used with rpm -U, nor rpm -i. [3] Changes between original and censored list of items http://fedoraproject.org/wiki/AxelThimm/kmdls/kmods_vs_kmdls_at_a_glance?ac… By order of importance: o rpm & kmods: "breaks on rpm level" removed "rpm -i does not work" suddenly "works" ??? o kmod's need for further yum developend removed!!! o yum w/ full plugin support kmod's "only one kernel supportable [...]" becomes "possible" ??? kmdl's "full suport" becomes "possible" ??? The difference is a working kmdl plugin today vs the shown issues of the fedorakmod.py, which were even admited by pro-kmod participants. o kmods: kernel's evr "merged with the modules" becomes "available as provides" It is very important that the 2-dimensional evr space is mapped that way, it is in fact the root of most evil. Replacing it as done hides the issue. o kmdls and low maintenance: "specfile/src.rpm/userland invariant" becomes "every new kernel/flavour needs full rebuild" o kmdl's design flexibility/abstraction of interface/implementation removed o infrastructure (bugzilla/cvs/owners) benefits removed o custom kernel support removed o other distribution benefits of kmdls removed o cross-distribution standard benefits of kmdls removed o Removed column rating (that by itself I would consider OK) -- Axel.Thimm at ATrpms.net

1 0

RESEND: REPORT: IRC meeting to discuss kernel module packaging
by Jon Masters 18 Aug '06

18 Aug '06

[ Original message with attachment exceeded mailing list accepted size ] Hi folks, We just had a little gathering on #fedora-packaging to discuss what to do about kernel module packaging in FC6 and beyond. The logs are attached inline to this message for archival, though none of these points have been put to a vote at this point for an official seal. The inclination of most of us present was to accept my proposal that we fix the fedorakmod plugin to handle older kernels in time for FC6 (that being an identifiable key issue with kmods right now). We should then re-address the whole kernel module packaging standard in the FC7 time-frame with a view to considering how introducing kABI checks, fixing identified failings, and taking on comments from Axel (and others) can best result in an improved packaging system. We decided to have regular IRC meetings following FC6 in order to look again at the packaging process and make some recommendations for a new modified standard for packaging modules. Although we would like not to re-invent the wheel, there are legitimate issues to look at later on. Jon. P.S. http://fremont.jonmasters.org/~jcm/fedora-packaging_20060818.log -- Jon Masters Phone: +44 7776 131337 Red Hat UK, Ltd. Email: jcm(a)redhat.com

1 0

Python submodule naming
by Toshio Kuratomi 18 Aug '06

18 Aug '06

Luke Macken is working on a few python packages for infrastructure and has run across an unanticipated naming issue with python-pastedeploy and python-pastescript[1]_. Our present naming guidelines [2]_ say to use the name of the python module when it is imported. The question is how does this map to submodules? In this case: import paste.deploy import paste.script This could reasonably be named python-pastedeploy or python-paste-deploy. Do we want to specify that submodules be named one or the other or leave it up to the packager? For what it's worth, Debian has python-pastedeploy but also python-twisted-conch so they seem to leave it to the packager ATM. [1]_ https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00676.html [2]_ http://www.fedoraproject.org/wiki/Packaging/NamingGuidelines#AddonPython -Toshio

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging August 2006