Re: [Fedora-packaging] localizing spec summary ?
by Mario Blättermann
p, li { white-space: pre-wrap; }Hi Erik,
Am Donnerstag, den 10.03.2011, 14:58 -0500 schrieb Erik Blankinship:
> Where can I find documentation on how to localize the strings in my
> spec file, specifically Summary: ?
>
> from http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo
> Summary: A brief, one-line summary of the package. Use American
> English, and do not end in a period.
>
This is less documented. However, there's a short hint in the Mandriva wiki:
http://wiki.mandriva.com/en/Policies/Charset#Why.3F
I've used it in my packages:
http://dl.dropbox.com/u/19373040/Fedora/SPECS/cputnik.spec
It works fine, gnome-packagekit shows the translated versions.
I hope we will have a translation routine for package summaries and descriptions in the future, as known from other distributions, such as Ubuntu or Mandriva. To setup a working installation on Koji is difficult, I'm sure. But the translations itself could be reused from the mentioned distributions.
Best Regards,
Mario
13 years, 2 months
pre-compiled binaries in SRPM/source tarball
by jan.klepek
Hi,
I have question, when I got tarball from upstream or I'm creating
tarball by myself from their git repo, which contains binary (exe) file.
Is there any packaging guideline that forces me to exclude this binary
file before tarball is created/used in srpm?
Christopher Aillon is trying to convince that below guideline has to be
applied to source tarball also.
http://fedoraproject.org/wiki/Packaging/Guidelines#No_inclusion_of_pre-bu...
However I don't see any reference to SRPM/source tarball and I was in
impression that this is only for final (builded) rpm as otherwise it
would break review guidelines (rule for comparing source tarball in SRPM
and tarball from upstream).
Thanks for answer.
Regards,
Jan Klepek
13 years, 2 months
Remove requirement to use macros for paths
by Toshio Kuratomi
Recently the question of why we require people to macroize their paths in
spec files (and by extension, patch build scripts to use the expansion of
our macros instead of hardcoded values) came up. FPC only knew of one, not
so great reason: if the paths were to change, for instance a change in the
FHS, then spec files that use macros (in both the spec file and the
expansion of those macros is used in the upstream build scripts) would only
need a rebuild to pick up th new paths.
I then opened this ticket: https://fedorahosted.org/fpc/ticket/67
for FPC to consider dropping using the directories as a requirement.
As recorded in the comments, some people have stepped forward with the
additional rationale that third-parties rebuilding our packages may wish to
install their rebuilds into a separate directory structure for their own
tracking purposes. Having directory paths in macros allow them to do that
by redefining %{_prefix}, %{_sharedstatedir}, and a handful of other
toplevel directory macros. If we allowed hardcoding of directories, then
they'd have to edit the spec file to achieve the same goal.
If people have additional reasons that macroizing all directory paths make
sense, please let us know (here or as a comment in the ticket). Then FPC
can decide whether to relax this rule or update the rule with information
about why we have it in place.
Thanks,
-Toshio
13 years, 2 months
Systemd guidelines architectural decisions to be made
by Toshio Kuratomi
https://fedorahosted.org/fpc/ticket/31
Okay, we ran out of time at today's meeting so I'm going to post the list of
architectural decisions FPC needs to decide on in order to keep going on the
systemd guidelines.
Status report on bugs:
* I've submitted a patch to notting to fix the chkconfig bug introduced by
having chkconfig fallback on calling systemctl:
https://bugzilla.redhat.com/show_bug.cgi?id=616857
We should be able to use chkconfig --no-redirect in our scriptlets once
that's applied
* I've fixed a lot of bugs in the proposed scriptlets and added some notes
about other issues discovered to the scriptlets on the guidelines. Some
of those issues lead to the decisions we need to make next:
= Triggers or no triggers =
notting raises the point in the Guidelines ticket that triggers are
conceptually the right tool for this job. Additionally, I think that some
of the things we're trying to do are very difficult without triggers. For
instance, telling the difference between a systemv init script that exists
from an old package versus a systemv init script that exists from a new
package is not possible just by using chkconfig. So we can't tell using
just chkconfig if we are supposed to run a migration from systemv init
script to systemd or not:
foo-1.0 has only a SysV init script in /etc/init.d/foo
foo-2.0 has both a SysV init script and a unit file in
/lib/systemd/system/foo
foo-2.1 has both a SysV init script and a unit file.
If I do yum upgrade foo and it wants to install foo-2.1, how do I know if
foo-1.0 or foo-2.0 is what is being replaced in %post? If I don't know,
then how do I know whether to try to migrate the runlevel information from
the systemv init script?
If other FPC members feel strongly that we still want to avoid triggers,
we can try to eliminate each of the corner-case scenarios and see if we can
avoid them but my present inclination is that triggers are the way to go.
= Migration of user customization =
A lot of the other discussion in the FPC ticket right now is how to migrate
information about what services are started. This includes what runlevels
to migrate and also which commands to use to perform the migrations. I'll
list the options that I can think of in a bit but I think the basic question
is: do we want the user's system settings to just work when they do an
upgrade or do we want them to start over with our defaults, redoing any of
their customizations?
== Starting over with the defaults ==
If the latter, the option that I think works best is to use systemctl enable
in if the package being upgraded from is a sysVinit user. Using trigger
scripts, this would be implemented something like this:
%post
if [ $1 -eq 1 ] ; then
# Initial installation
# If a package is allowed to autostart:
/bin/systemctl enable foo.service >/dev/null 2>&1 || :
# No autostart:
# /bin/systemctl daemon-reload >/dev/null 2>&1 || :
fi
# Note: the NEVR in trigger scripts should all be the version in
# which the package switched to systemd unit files and the comparision
# should be less than. Using <= the last version with the sysV script won't
# work for several reasons:
# 1) disttag is different between Fedora releases
# 2) An update in an old Fedora release may create a newer NEVR
%triggerun -- foo < 1.0-2
# Run this because the chkconfig --del in the SysV providing package won't
# fire unless the package is removed
/sbin/chkconfig --del bar >/dev/null 2>&1 || :
# I think that we need this as well
# /bin/systemctl try-restart foo.service >/dev/null 2>&1 || :
# If the package is allowed to autostart, do the following
/bin/systemctl enable foo.service >/dev/null 2>&1
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
(The %preun and %postun will remain as they are in the current proposal)
In this example, systemctl enable is working similarly to chkconfig --add.
It looks in the unit file for the Wanted-By entry. Then it enables the
service in all of the targets listed there.
=== Some thoughts on this ===
Under this model, it would be most user friendly if we migrated to systemd
unit files all in one release cycle. Failing that, it would be user
friendly to have a policy that pacakgers must not update from sysv to
systemd scripts over the course of a released Fedora. The reasoning behind
either of those rules would be that services may be enabled or disabled when
a package updates from the systemV to the systemd version so we'd want to
minimize that happening when the user doesn't expect.
Failing either of those, this will only hit the user once per package that
they have installed that migrates from sysV to systemd which may or may not
be acceptable.
== Migrating the user's settings ==
If we do think that we should be migrating the user's settings then we need
to think about what customizations the user may have performed and how we
can migrate them to a systemd equivalent. For the purposes of the
Guidelines, the user may have turned a service on or off in a particular
runlevel. Of the runlevels that system v init provides, there are five that
have a definite meaning with a map into systemd: 1 => rescue, 3 =>
multi-user, 5 => graphical, 0 => poweroff, and 6 => reboot. Of these, 0 and
6 don't seem to have any scripts in Fedora that are designed to start there
so we don't need to migrate anything that the user customized.
The other three can be migrated so that the user can use those targets under
systemd and have them start the same programs as they did when they were
using systemv initscripts. Migrating a service for a particular target
seems to need to use explicit symlinking; systemctl doesn't appear to have
a command that does that. The %triggerun script would look something like
this (the other scripts stay the same as the previous example):
%triggerun -- foo < 1.0-2
/sbin/chkconfig --del bar >/dev/null 2>&1 || :
if chkconfig --level --no-redirect 1 foo ; then
ln -sf /lib/systemd/system/foo.service /etc/systemd/system/rescue.target.wants/ 2>&1 >/dev/null
multiuser=0
if chkconfig --level 3 foo; then
ln -sf /lib/systemd/system/foo.service /etc/systemd/system/multi-user.target.wants/ 2>&1 >/dev/null
multiuser=1
fi
if chkconfig --level 5 foo; then
# If it's already in multi-user, it will be inherited automatically
if [ $multiuser -eq 0 ] ; then
ln -sf /lib/systemd/system/foo.service /etc/systemd/system/graphical.target.wants/ 2>&1 >/dev/null
fi
else
if [ $multiuser -eq 1 ] ; then
# We have the option of disabling the service in graphical here to
# match what the user explicitly customized their system to like
# this:
ln -sf /dev/null /etc/systemd/system/graphical.target.wants/foo.service
# But we could also decide that this is not something that we're going
# to migrate (as systemd itself sets graphical up as a strict
# superset of multi-user).
fi
fi
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
= Migration between sysv and systemd settings post-package changes =
Also raised in the ticket is whether we should support moving back to
sysvinit. My view on that is that we should allow a user installing and
customizing a systemVinit system in parallel to the systemd files without
getting in their way but we shouldn't explicitly support migration from
the default init system to another init system in the standard packaging
guidelines. We can certainly have guidelines for each individual init
system that people who write scripts for them may follow but setting up
which runlevel-equivalents each of those start services in should be
independent of what's being done in systemd.
I think that's the basics of the issues we need to work on to keep moving
forward on the guidelines. There's certainly more information and
informational questions that could be asked and answered to make informed
decisions here, though. discuss away.
-Toshio
13 years, 3 months
Glabels package v3.0
by Mario Blättermann
Hi all,
the current glabels package v2.2.8 will probably shipped with F15. There
is a development version 2.3.1 (using the newest GNOME technologies such
as GSettings, GTK3, Mallard docs etc.), which will be likely replaced
with the final 3.0 next weeks. Currently glabels-2.3.1 is installable
parallel to glabels 2.2.x, the packages doesn't conflict with each
other. Does it make sense to provide a new package, or should the old
one be replaced?
FYI, I'm the co-maintainer of the glabels project. We will keep the
mentioned feature for a while, let's say until v3.0.1 will be released,
or even longer, if desired. In my mind, we should give users a chance to
test the new GUI and its behavior, before we deprecate glabels 2.2.8.
Any opinions?
Best Regards,
Mario
13 years, 3 months
Question about missing CGI.pm
by Mike Ramirez
I wnet to #fedora first, they sent me to upstream, I checked with #perl, no
reply. Then I realized this is the probably the best place to ask.
I had an issue earlier where CGI.pm wasn't installed (or in the @INC path).
Searching a bit more shows me that perl-core meta-package (not installed)
lists it as a dependency (requires perl-CGI), perl package says it provides it
though [1]. This is fedora 13 installed from the KDE spin.
Also, I don't install many perl packages for my own use, so the packages that
depend on it are not installed. Which this and the KDE spin base, makes me
suspect this makes it a race condition.
I also saw the bug report (Bug 486579 ) but was listed as wont fix (this
suggests splitting perl-CGI into two seperate packages), it appears to have
been rejected as a wontfix
Technically, the question is, why isn't CGI.pm installed/available with just
perl, is this a bug, race condition or expected behavior?
The reason this comes up is that Go lang just introduced new tests that
require CGI.pm, which is what I require it for. The go team is going to change
the tests to skip it if CGI.pm isn't available I think.
I did fix this with `yum install perl-CGI`.
Also the go maintainer might want to add this to the spec file for go-lang
with the rpm that distributes the tests.
Mike
[1] http://pkgs.org/fedora-13/fedora-
x86_64/perl-5.10.1-112.fc13.x86_64.rpm.html
--
Operators killed by year 2000 bug bite.
13 years, 3 months
RFC: No longer split out Elisp source into sub-packages
by Jonathan Underwood
Dear All,
While reviewing the (X)Emacs packaging guidelines today when drafting
the (x)emacs-filesystem changes (see other thread) it occurred to me
that we could simplify matters a lot by no longer insisting that the
Elisp source files be shipped in a separate sub-package to the
compiled Elisp. The original rationale was to follow the precedent set
by the main (X)Emacs packages where the sub-packaging of the Elisp
source files was done to save disk space. Nowadays that's much less of
a concern IMO.
Furthermore, having the Elisp source installed is helpful when an
error occurs in the compiled elisp invoking the elisp debugger - the
debugger can find the relevant symbols in the source Elisp if it is
available. In this sense, they are somewhat like the python .py
sources that we ship together with the byte compiled .pyc.
So, I am thinking of proposing that we:
1) Package the elisp source together with the compiled elisp in both
Emacs and XEmacs packages
2) Package compiled and source elisp files together in add-on packages.
This would simplify packaging add-ons, and reduce the number of
sub-packages in the repos (often the elisp source file packages
contain only 1 or two files), reducing the amount of yum metadata etc.
Also, note that the elisp source files can be gzipped and still be
read by (X)Emacs, reducing the disk space required.
Thoughts? If this is seen as a welcome change I'll draft up a guideline change.
Please note that this is entirely orthogonal to the guideline change
related to (x)emacs-filesystem usage that I have already put a ticket
into FPC for.
Cheers,
Jonathan.
13 years, 3 months
RFC: Update to XEmacs packaging guidelines [(x)emacs-filesystem]
by Jonathan Underwood
Dear All,
I've just submitted a ticket to FPC to update the (X)Emacs packaging
guidelines. Please see:
https://fedorahosted.org/fpc/ticket/68
The reason for this proposed update is as follows.
Consider the following very common situation: a package's principal
functionality does not require (X)Emacs, but the package also includes
some auxiliary Elisp files to provide support for the package in
(X)Emacs.
Presently the (X)Emacs guidelines require that the package split those
Elisp files out into a subpackage (called emacs-foo) which Requires
(X)Emacs. This was done to avoid the main package dragging in (X)Emacs
and related dependencies for when a system administrator doesn't want
to install (X)Emacs; this is necessary as the (x)emacs-common packages
own the /usr/share/site-{lisp|package} directories where the Elisp
files would be installed.
Ville Skytta recently suggested that a better solution is to create
emacs-filesystem and xemacs-filesystem sub-packages which own the
/usr/share/site-{lisp|package} directories. This then allows packages
to drop Elisp files into the (X)Emacs tree without pulling in (X)Emacs
as dependencies. This has now been done.
Therefore I have updated the Emacs packaging guidelines to reflect
this change. Please see the updated draft here:
https://fedoraproject.org/wiki/PackagingDrafts/Emacs
Comments welcome!
Best wishes,
Jonathan.
13 years, 3 months
