packages which add user accounts: is fedora-usermgmt the way?
by Matthew Miller
Is there an official policy for what packages that add users for their
processes to run as ought to do? I notice the recent clamav package still
uses fedora-usrmgmt, but I can't find any reference to that in the current
wiki, and that package still has the obsolete fedora.us wiki as its URL.
What's the Right Thing here?
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 77 degrees Fahrenheit.
17 years, 8 months
kernel-modules in the buildsystem (Was: Re: Stuff to look for in plague 0.4)
by Thorsten Leemhuis
CC fedora-packaging because this concerns kernel-module-packaging
Am Dienstag, den 23.08.2005, 01:18 -0400 schrieb seth vidal:
> On Sat, 2005-08-20 at 12:17 +0200, Thorsten Leemhuis wrote:
> > Am Freitag, den 19.08.2005, 21:40 -0400 schrieb Dan Williams:
> > > Quite a few things will change for plague 0.4:
> > > [...]
> > > If anyone has more thoughts, file some RFEs in bugzilla for Fedora Extras
> > > Infrastructure.
> >
> > What is the current status of passing special options to the actual
> > rpmbuild call? We should have those for building kernel-modules because
> > building kernel-modules for a lot of different kernels would be much
> > easier if no changes to the actual kernel-module-specfile are needed. In
> > the current KernelModuleProposal-Example2 (*1) this is realized by:
> >
> > %{!?kver: %define kver %(uname -r)}
> > [...]
> > make KVERS=%{kver} KSRC="%{_usrsrc}/kernels/%{kver}-%{_target_cpu}" -C driver
> >
> > So if someone builds the src.rpm at home it is rebuild for the current
> > kernel. When build with mock the buildsystem should defined kver.
> > Something like:
> >
> > for kernel in <list of target kernels [example: current-kernel.i586 current-kernel.i686 current-kernel-smp.i586]>
> > do
> > mock build /path/to/srpm --define "kver $kernel"
> > done
> >
> > AFACS we need support for this in both mock and plague (or is something
> > like that already possible? mach can pass options to rpmbuild, mock
> > can't iirc)
>
> I do not think that adding this into mock or rpmbuild is a good idea,
> honestly.
For other packages I agree. Kernel-modules should be a exception IMHO.
> If the package won't built w/o arbitrary defines then we'll
> have a devil of a time figuring out how to REBUILD it later.
It builds for the normal user without arbitrary defines. And even
better: It automatically builds what you probably want, because with the
above it builds the kernel-module for the currently running kernel. If
you get a random kernel-module.src.rpm where kver ist hardcoded you have
to edit it each time to get compile against a new kernel.
BTW, this is in all three proposals in
http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal
If we all agree that we don't like passing arguments to rpmbuild then we
should restart the kernel-module-discussion on fedora-packaging.
CU
thl
17 years, 9 months
Kernel Module Packages
by Andreas Gruenbacher
Hello,
I have thought about rpm packages containing kernel modules independently of
the threads in this mailing list, which Matt Domsch was friendly enough to
pointed me at --- thanks, Matt. Maybe we can share some thoughts, and even
move our implementations a little closer together.
We've been looking at DKMS, and decided not to use it in favor of a purely rpm
based solution, so that the rpm database knows which modules belong to which
packages, etc. That's the same as with your proposals on
http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal.
One of the benefits of DKMS we saw was the ability to query which driver
packages were installed for a specific kernel. The same can be achieved by
checking which packages beside the kernel package itself install *.ko files
below /lib/modules/$(uname -r), so we'll achieve this feature by a script
that does that. Easy enough.
You seem to also prefix kernel module package names with ``kernel-module-'' to
make them easier to identify. Not really necessary I believe, especially
since they can as well be listed with --whatrequires.
We thought it useful to include a unique provider prefix in the package name
though, so that different vendors won't produce name clashes. Our plan was to
use the LANANA provider names registry (http://www.lanana.org/) for that.
The driver name, driver version, and kernel release ($KERNELRELEASE) are also
stored differently in rpm tags: our build system likes to be able to freely
assign the package release number, so we don't store extra information there.
Rather, we put the driver version in the Name, and the kernel release in the
Version:
> %define provider_prefix novell
> %define driver_name foo
> %define driver_version 1.1
> %define flavor smp
>
> %define kver %(rpm -q --qf '%{VERSION}-%{RELEASE}' kernel-source)
>
> Name: %provider_prefix-%driver_name-%driver_version
> Version: %(echo %kver-%flavor | tr - _)
> Release: <arbitrary>
> Requires: kernel-%flavor = %kver
The kernel version and release %kver is determined by the installed
kernel-source package.
The %flavor thing deserves some explanation: for each architecture, we have a
number of differerent kernel configurations which we call "flavors". The
config files for those flavors are found in arch/$ARCH/defconfig.$FLAVOR in
the SUSE kernel-source package, by the way. The kernel packages are called
kernel-$flavor, with version and release %kver. They additionally provide the
symbol kernel = %kver. There is some documentation at
http://www.suse.de/~agruen/kernel-doc/, in case anybody is interested.
Storing the driver version in the package name allows driver vendors to offer
multiple versions of the same driver for use with the same kernel. These
packages won't interfere with each other on updates, unless one of the
drivers Provides and Obsoletes another. We have learned with pain that
vendors sometimes drop features in drivers with higher versions, leading to
interesting customer situations. Because of that, we want kernel updates to
update driver versions only if explicitly requested.
One feature we allow is, we allow modules for multiple flavors (from the same
architecture) in the same kernel driver package. For example, a kernel driver
package could contain modules for 2.6.13-rc6-1-default, 2.6.13-rc6-1-smp, and
2.6.13-rc6-1-xen. It is very easy to build those modules, and most modules
are really small, so this reduces the number of packages we need to build,
and manage. In that case, the Version and Requires tags change to:
> Version: %(echo %kver | tr - _)
> Requires: kernel = %kver
Another interesting case is module package reuse: often modules from the
previous kernel can be reused with the new kernel after a kernel upgrade, in
case a new module package is not available. Dropping driver packages might
render systems unbootable (consider a raid adapter driver or similar).
It's quite easy to check if the modversions a module requires have changed. We
offer to reuse module packages if possible. When a user choses to reuse a
module package, we repackage the files in the old module package for the new
kernel, and move modules from /lib/modules/$old_kernel
to /lib/modules/$new_kernel. That way we can keep proper record in the rpm
database, and everything stays nicely manageable.
What I'm also missing in your proposals is mkinitrd calls: When modules that
are part of initrds get replaced, you also want to update it the initrds I
guess.
Regards,
Andreas.
17 years, 9 months
To .pyo or not to .pyo?
by Orion Poplawski
I'm a python neophyte, but I've been packaging some python packages and
have questions about .pyo files. I've gotten various feedback about
including them, not including them, and using %ghost on them. Can
someone please explain what the issues are (both with arch and noarch
packages)? Also, what does %ghost do?
Thanks!
--
Orion Poplawski
System Administrator 303-415-9701 x222
Colorado Research Associates/NWRA FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com
17 years, 10 months
rpmlint warning
by Orion Poplawski
Can someone explain this rpmlint error?
E: plplot-tk no-dependency-on locales-tk
--
Orion Poplawski
System Administrator 303-415-9701 x222
Colorado Research Associates/NWRA FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com
17 years, 10 months
updating versions policy
by Michael A. Peters
I know that with shared libraries, it generally is not a good idea to
push an update that involves versioning a shared library because the
user may have software their system that is linked against the older
shared library, but is there a general policy about other software?
One of the packages I maintain in Extras is likely to be named as a
sourceforge project of the month. The upstream developer is working
overtime to finish implementing some things before that happens. The
package is gourmet (PyGTK recipe manager) and absolutely nothing depends
upon it - and I'm thinking that when he has these things finished, that
might be a good time to update the package in Extras.
Since it is not a package which is designed to have anything else depend
on it, I'm assuming there is not a problem with a version update in
Extras? Is that the case?
The project is under fairly rapid development but I don't intend to
package every little update simply because most of them don't add
anything worth an update imho, but I think the update he is planning
(after testing) is will be worth pushing an update.
17 years, 10 months
Tool to determine what files require what
by Orion Poplawski
I'm packaging some software that provides interfaces for lots of
different libraries and languages. I'd like to split it up into
sub-packages for the different components. It would be useful to have a
tool that would report a "requires" for each file in the package in
order to "sort" them into the different sub-packages.
Any suggestions?
--
Orion Poplawski
System Administrator 303-415-9701 x222
Colorado Research Associates/NWRA FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com
17 years, 10 months
Using %{dist} for conditional compilation
by Orion Poplawski
Is it kosher to use the %{dist} tag for conditional compilation? The
shift from g77 to gfortran in FC3->FC4 has led to the need to compile
packages differently for the two distributions.
--
Orion Poplawski
System Administrator 303-415-9701 x222
Colorado Research Associates/NWRA FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com
17 years, 10 months