Retrograde package version
by W. Michael Petullo
I recently followed another distribution's lead and made some assumptions
about the version numbering of a package I maintain, mt-daapd.
I released a bugfix in the form of:
mt-daapd-0.9-0.4.1696.fc8
mt-daapd-0.9-0.2.1696.fc9
mt-daapd-0.9-0.2.1696.el5
I had thought that the next release would be in the 0.9 series.
Now, the bugfix is upstream and the author has released the next version
of mt-daapd. Unfortunately, this version is 0.2.4.2, which is lower that
the versions above. I'd like to supercede the packages above with this
"lower" version number.
What is the best way to handle this? I'd like to avoid using the 0.9
version, as the developer has not moved to this yet upstream.
Mike
16 years
Policy question: how tight should cross-subpackage Requires be?
by Tom Lane
Is there, or should there be, any Fedora packaging policy about the
following question? (I see nothing in the Guidelines at the moment.)
Given a single SRPM generating multiple sub-RPMs, some of which depend
on each other, how hard should the maintainer try to ensure that
matching versions of the sub-RPMs are installed? Possible answers
include:
1. Do nothing, rely on automatically generated requires (eg, the major
version of a shared library's soname). Maximum flexibility, maximum
possibility of allowing installations that don't actually work.
2. Put in cross-package requires of the form
Requires: %{name}-libs = %{version}
ie, constrain to "same upstream version"
3. Put in cross-package requires of the form
Requires: %{name}-libs = %{version}-%{release}
ie, constrain to "exact same build"
Currently, I have some packages that do #2 and some that do #3,
and I have an open bug suggesting that #3 is the way to go because
it ensures yum will update all installed subpackages together:
https://bugzilla.redhat.com/show_bug.cgi?id=444271
However this idea was questioned on an upstream mailing list
on the grounds that users shouldn't be forced to update all
subpackages together.
I've got mixed feelings about it myself. I see the point about
not constraining users unnecessarily, but there is no way that
anyone is ever going to have done any testing on mix-and-match
installations --- certainly I haven't got time to. (As an example
of possible problems, different %{release} builds might have used
different configure options, leading to builds that really are
incompatible.) I think I'd rather ship RPMs that try to enforce
that only tested combinations are installed. There's always
--nodeps for those who think they're smarter than me...
So, first, has anyone got an opinion about this, and second,
should a policy recommendation be enshrined?
regards, tom lane
16 years
Re: python packaging - icons/desktop files and /usr/bin accessibility
by Mary Ellen Foster
[ NB: I sent this to fedora-packaging as well as fedora-devel, and
it's probably better to follow up there because this thread is
shifting focus ... ]
On Mon, May 5, 2008 at 10:54 PM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
> I took a closer look at Ice and I think there's a few things that should
> change.
>
> 1) AFAICS there's no reason for the python bindings to be part of the Ice
> package. It comes in a separate tarball and appears to build on its own. I
> can't find a mention of this in the review so I don't know if there's
> something special about it that I'm missing. [1]_
Actually, upstream is very soon releasing a new version of Ice where
all of the language bindings are in a single tarball, so I think I'll
stick with the monolithic SRPM.
> 2) The .pth file looks like it's being used to compensate for bad imports
> and upstream packaging.
> * There should be an __init__.py file in
> %{_libdir}/pythonX.Y/site-packages/Ice
>
> * The following files have imports that need to be changed:
> IceBox/__init__.py
> Glacier2/__init__.py
> IceGrid/__init__.py
> IceStorm/__init__.py
> IcePatch2/__init__.py
>
> change imports like::
> import IceBox_IceBox_ice
> to this::
> from Ice import IceBox_IceBox_ice
The problem is, those files are automatically generated using other
parts of the Ice program (using slice2py, to be specific). There's a
documented way that slice2py deals with packages and modules
(http://zeroc.com/doc/Ice-3.2.1/manual/Python.23.15.html#75777) that
I'm reluctant to touch.
I could remove the "Ice.pth" file and require people to set
PYTHONPATH, but unfortunately I don't think I can go changing the
actual (generated) __init__.py files. :(
> 3) Additionally, on x86_64, the python module is spread over two
> directories: /usr/lib64/python2.5/site-packages/Ice and
> /usr/lib/python2.5/site-packages/Ice. Python doesn't handle that very well.
> All the files of a module should be in a single directory. Since this
> module builds an ELF shared object (IcePy.so/IcePy.so.3.2.1) all files
> should be installed into %{python_sitearch}/ (This is what lead to BZ
> #392751).
Okay, sure, that's easy to fix. So I should put *.py* into site_arch
always, and put nothing into site_lib? The Python packaging guidelines
aren't amazingly clear on this point to a non-Python programmer like
me. :)
MEF
--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh
16 years
desktop file validation
by Christopher Aillon
I got recently called out for using desktop-file-validate instead of
desktop-file-install when the upstream .desktop file is correct, doesn't
need to be changed, and make install already places it in the correct
location.
Since the purpose of this guideline is to validate, I propose to amend
the section of the packaging guidelines on desktop-file-install usage[1]
as follows:
* Rename the sub-heading from "desktop-file-install" to ".desktop file
installation and validation"
* Change the first sentence to:
<<
It is not simply enough to just include the .desktop file in the
package, one MUST run desktop-file-install OR desktop-file-validate in
%install (and have BuildRequires: desktop-file-utils), to help ensure
.desktop file safety and spec-compliance. desktop-file-install MUST be
used if the package does not install the file or there are changes
desired to the .desktop file (such as add/removing categories, etc).
desktop-file-validate MAY be used instead if the .desktop file's
content/location does not need modification. Here are some examples of
usage:
>>
* Add the following example:
<<
desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
>>
Thoughts?
[1]
http://fedoraproject.org/wiki/Packaging/Guidelines#head-d559ee7363418a584...
16 years
Copyrighted specfiles.
by Brad Bell
Are specfiles covered by the Individual Contributor License Agreement
(CLA) ?
http://fedoraproject.org/wiki/Legal/Licenses/CLA
>
> Message: 1
> Date: 29 Apr 2008 22:42:46 -0500
> From: Jason L Tibbitts III <tibbs math uh edu>
> Subject: [Fedora-packaging] Copyrighted specfiles.
> To: fedora-packaging(a)redhat.com
> Message-ID: <ufak5ig1009.fsf(a)epithumia.math.uh.edu>
> Content-Type: text/plain; charset=us-ascii
>
> I have a specfile that begins with:
>
> # Copyright 2006-2008 Double Precision, Inc.
> # See COPYING for distribution information.
>
> It looks like the specfile is carried in the tarball and the
> maintainer just copies it out for the Fedora package. But this means
> that when you unpack the srpm, you get a spec that refers to a file
> which does not exist.
>
> Is it too much to ask that if for some reason you're going to
> copyright the specfile you at least indicate the license in the
> specfile?
>
> - J<
>
>
>
>
16 years, 1 month
