packaging February 2005

packaging@lists.fedoraproject.org

19 participants
9 discussions

Naming Policy (first draft)
by Tom Callaway 02 Mar '05

02 Mar '05

Working as fast as I can... here is the first draft of the Naming Policy for Fedora Extras. Its not 100% complete yet, there are at least two sections missing, but it covers the bases for most new packagers. http://fedoraproject.org/wiki/PackageNamingGuidelines Feedback is welcome, and encouraged. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!

14 77

Template .spec file for conventions?
by Scott Lawrence 01 Mar '05

01 Mar '05

It looks as though there's a consensus developed around how packages should be named. Being fairly new to rpm building, I have not understood all the details of the discussions around how best to implement those conventions. Might it be possible for one of you who does understand it to supplement the naming guidelines with a skeleton .spec file that illustrates how to do it, along with whatever is required of the surrounding build system? -- Scott Lawrence Consulting Engineer Pingtel Corp. http://www.pingtel.com/ +1.781.938.5306 x162

4 3

PackageNamingGuidelines comments
by Elliot Lee 01 Mar '05

01 Mar '05

Hi guys, I'm late to the party, but overall it looks good. The stuff that could improve is eliminating "non-numeric version in release". For the sake of keeping things sane and simple, the Version: should normally match the upstream version. If there are versions such as 0.1beta that compare as "greater than" 0.1, then epoch should be used. That's one of the situations that epoch was created for. Making rules about munging version & release in the general case, for the sake of avoiding epoch in the special case, just complicates things unnecessarily. Inter-repo wars are going to exist whether or not Fedora chooses to use epoch - they have no bearing on this decision. Cheers, -- Elliot

9 17

Introduction
by Tom Callaway 28 Feb '05

28 Feb '05

Howdy! I'm the sucker who volunteered to head up RPM Standards and Practices for Fedora Extras. I'd like to make a few things clear, before we get to the good stuff: Check your egos at the door. If all you feel like doing is posturing, flaming, or mocking, this is NOT the list to do it in (I hear fedora-list is nice this time of year). If I think you're being more of a nuisance than an asset, I will warn you, then kick you off the list if you continue. I hope it doesn't come to that. Keep an open mind, and back up your opinions. Disagree, but do so politely. Be patient with me. I have a wife, a linux distribution, and a full time job that has nothing to do with Fedora Extras. I wasn't involved in the fedora.us period, so don't assume I know anything. I am not interested in overhauling the existing RPM standards and practices. My task is to identify and document the existing standards and practices, highlight problems in the Fedora Extras packaging world, get them solved in a maintainable fashion. Thanks in advance for your help and time, ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!

3 3

Re: Epoch policy
by seth vidal 27 Feb '05

27 Feb '05

On Sat, 2005-02-26 at 16:53 +0100, Aurelien Bompard wrote: >Hi all > >In the new PackageNamingGuidelines, there is nothing about epochs. What is >the new Extras policy regarding Epochs ? New packages should be created >without Epochs, but what about Fedora.us imported packages ? Should I drop >Epoch in the next releases ? Should I do it only for the devel branch ? 1. Look on the fedora-packaging list for the discussion 2. my guess is: a. if the fedora.us package had a non-zero epoch it needs to be maintained - just so users have an upgrade path b. if the fedora.us package had an Epoch: 0 drop it and remove %{epoch} from anyplace you have it in ver strings. I'm cc'ing the packaging list to see if that seems right to them. -sv

5 5

RFC: howto to package LaTeX classes
by Jose Pedro Oliveira 27 Feb '05

27 Feb '05

Hi, Are there any recommendations regarding TeTeX packages? In particular I have a few doubts/questions regarding: * license Question: Is the "LaTeX Project Public License" an approved license? Note: The rpmlint emits the following warning regarding the license ... W: tetex-xcolor invalid-license LaTeX Project Public License * name conventions for tetex related macros - texmf base directory - package base directory - package documentation base directory (texdoc related) - texhash program (or mktexlsr) Example: %define _texmf %{_datadir}/texmf %define __texhash %{_bindir}/texhash %define texpkg xcolor %define texpkgdir %{_texmf}/tex/latex/%{texpkg} %define texpkgdoc %{_texmf}/doc/latex/%{texpkg} * installation scripts (texhash vs mktexlsr) Problem: the texhash file is owned by different packages $ rpm -qf /usr/bin/texhash FC1: tetex-2.0.2-8 FC3: tetex-fonts-2.0.2-21.3 Solution: Use the file as a requirement ---------- ... Requires(post): %{__texhash} Requires(postun): %{__texhash} ... %post %{__texhash} %{_texmf} >/dev/null 2>&1 || : %postun %{__texhash} %{_texmf} >/dev/null 2>&1 || : ... ---------- * installation of package documentation in order for it to be found by the texdoc program Problem: - the texdoc program only searches for documentation files under the directory /usr/share/texmf/doc/ - I believe the tetex package documentation should be installed in directories like /usr/share/texmf/doc/latex/"package_name" but /usr/share/texmf/doc is owned by tetex-doc which is a rather big package (50MB+) to be a requirement. Is it ok for tetex-* packages owning this directory? I am packaging the latex Beamer presentation class and its two dependencies (xcolor and pgf). I have looked at several tetex-* packages (fedora us/extras) and almost everyone of them seems to be doing different thing. It would be nice to have a specfile template. Comments/suggestions are welcome, jpo References: * The Beamer presentation class http://latex-beamer.sourceforge.net/ * The Xcolor dependency http://www.ukern.de/tex/xcolor.html * Two of my tetex specfiles http://gsd.di.uminho.pt/jpo/software/RPMS/tetex-xcolor.spec http://gsd.di.uminho.pt/jpo/software/RPMS/tetex-xcolor-2.00-1.src.rpm http://gsd.di.uminho.pt/jpo/software/RPMS/tetex-pgf.spec http://gsd.di.uminho.pt/jpo/software/RPMS/tetex-pgf-0.65-1.src.rpm PS - I forgot to mention that I am not a TeX/LaTeX expert. -- José Pedro Oliveira * mailto: jpo(a)di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *

3 3

Re: DKMS into Fedora Extras
by seth vidal 24 Feb '05

24 Feb '05

On Mon, 2005-02-21 at 13:19 -0600, Tom 'spot' Callaway wrote: > On Mon, 2005-02-21 at 14:05 -0500, seth vidal wrote: > > >we might be able to do something like: > >if two kernel modules have the same name but different versions then > >it's an update. > > > >that would require: > > - kernel-version-in-module-package-name > > - provides: kernel-module in the header > > - consistent use. > > I think that's doable. Lets take this thread over here: > https://www.redhat.com/mailman/listinfo/fedora-packaging Right now yum does the following: if it is a kernel or kernel module (ie provides kernel or provides kernel-modules) then the package is installed not updated. if we can come up with a consistent pattern for when a kernel-module will be updated but not installed then I can add it into the function that determines that sort of stuff. Right now I'm thinking: kernel modules must have kernel-version-release in the package name for the kernel module - this makes for irritating package naming and cvs naming but <shrug> if a kernel-module has a new version available then it should be updated, not installed. else - kernel modules are installed. Now - how do we go about getting kernel modules pulled in when new kernels come out. Clearly it can't be via an update b/c the package name will change, so yum won't notice it as an update. Doing it via obsoletes is just yucky. We need something like a kernel-module registry. So we can track kernel-modules you have installed by something OTHER than package name. Thoughts? -sv

7 33

Overlapping/variant rpms - how to ensure correct resolution
by Scott Lawrence 23 Feb '05

23 Feb '05

I'm the project coordinator of the sipXpbx project [1] and we're distributing quite a number of RPMs (in the fullness of time we'd like to get them into Extras, but that is a topic for another list and another day) . The project itself consists of several component RPMs and there are some other open source projects on which we depend that we build RPMs for, mostly because they don't. The one exception to the "mostly because they don't" is the difficulty I'm looking for advice on from those who understand packaging. Fedora Core inludes w3c-libwww.rpm, but that version does not include compilation with openssl. For lots of good reasons, we need the openssl, so we build a version of the w3c-libwww.rpm that has it enabled; that's the only difference. Our first approach to dealing with the conflict was just to instruct our users to configure yum to exclude the w3c-libwww package from all repositories but ours, but that's a bit of a pain. We tried adding a 'requires' line to our spec file that called for 'libwwwssl.so' (which is in our rpm but not the Core rpm for the same package), but then yum seemed to want to load both... In any event, this seems to me to raise a general issue of how to cope with the fact that some packages can be built in (potentially overlapping) variants. How can we make all of the variants available and express what each provides so that tools like yum can make the correct choice? [1] http://www.sipfoundry.org/sipXpbx/ -- Scott Lawrence Consulting Engineer Pingtel Corp. http://www.pingtel.com/ +1.781.938.5306 x162

2 2

kernel-module package naming
by Tom Callaway 22 Feb '05

22 Feb '05

I don't think there is any dispute that magic will be needed to solve this problem. The more I think about it, the more I am opposed to abusing the package %{NAME} to solve it. Let's make the ground level assumption that packages containing kernel modules will be named %{NAME}-module, based on precedence in Fedora Core. So we'll have this: Fedora Core: GFS-module Fedora Extras: openafs-module unionfs-module Livna: ati-module nvidia-module >From there, we work uphill. ~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging February 2005