packaging August 2005

packaging@lists.fedoraproject.org

16 participants
9 discussions

packages which add user accounts: is fedora-usermgmt the way?
by Matthew Miller 12 Sep '05

12 Sep '05

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 80

kernel-modules in the buildsystem (Was: Re: Stuff to look for in plague 0.4)
by Thorsten Leemhuis 23 Aug '05

23 Aug '05

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

3 3

PDFlib-Lite license
by José Abílio Matos 22 Aug '05

22 Aug '05

Hi, I am starting the process of submitting grace to extras. One of its dependencies is PDFlib-Lite. The FAQ of the license is here: http://www.pdflib.com/purchase/license-lite.html The license itself is here: http://www.pdflib.com/products/pdflib/info/PDFlib-Lite-license.pdf Is this within the boundaries of extras? -- José Abílio Matos

3 3

Kernel Module Packages
by Andreas Gruenbacher 19 Aug '05

19 Aug '05

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.

4 9

To .pyo or not to .pyo?
by Orion Poplawski 11 Aug '05

11 Aug '05

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

2 3

rpmlint warning
by Orion Poplawski 09 Aug '05

09 Aug '05

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

2 1

updating versions policy
by Michael A. Peters 08 Aug '05

08 Aug '05

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.

3 3

Tool to determine what files require what
by Orion Poplawski 08 Aug '05

08 Aug '05

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

3 4

Using %{dist} for conditional compilation
by Orion Poplawski 01 Aug '05

01 Aug '05

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

9 15

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging August 2005