Mail voting on kmdl adoption
by Axel Thimm
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
16 years, 7 months
Packaging/Guidelines - Usage of %{optflags}
by Till Maas
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
16 years, 7 months
GConf snippets suggestion
by Yanko Kaneti
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
16 years, 7 months
Absolute symlinks
by Jason L Tibbitts III
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<
16 years, 7 months
Guidelines for packaging PHP
by Remi Collet
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.
16 years, 7 months
rpm -i, "missing" file conflicts and brokenness with kmods
by Axel Thimm
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
16 years, 7 months
kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file
by Thorsten Leemhuis
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.
16 years, 7 months
Complaints about censoring and kmdl IRC session (resend)
by Axel Thimm
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?...
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
16 years, 7 months
RESEND: REPORT: IRC meeting to discuss kernel module packaging
by Jon Masters
[ 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
16 years, 7 months
Python submodule naming
by Toshio Kuratomi
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
16 years, 7 months