Naming Policy (first draft)
by Tom Callaway
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!
18 years, 7 months
Template .spec file for conventions?
by Scott Lawrence
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
18 years, 7 months
PackageNamingGuidelines comments
by Elliot Lee
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
18 years, 7 months
Introduction
by Tom Callaway
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!
18 years, 7 months
Re: Epoch policy
by seth vidal
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
18 years, 7 months
RFC: howto to package LaTeX classes
by Jose Pedro Oliveira
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 *
18 years, 7 months
Re: DKMS into Fedora Extras
by seth vidal
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
18 years, 7 months
Overlapping/variant rpms - how to ensure correct resolution
by Scott Lawrence
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
18 years, 7 months
kernel-module package naming
by Tom Callaway
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!
18 years, 7 months
