packaging March 2011

packaging@lists.fedoraproject.org

25 participants
19 discussions

localizing spec summary ?
by Erik Blankinship 12 Mar '11

12 Mar '11

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. Thanks! Erik

2 1

Re: [Fedora-packaging] localizing spec summary ?
by Mario Blättermann 10 Mar '11

10 Mar '11

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

1 0

pre-compiled binaries in SRPM/source tarball
by jan.klepek 10 Mar '11

10 Mar '11

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-buil… 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

5 7

Remove requirement to use macros for paths
by Toshio Kuratomi 09 Mar '11

09 Mar '11

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

8 9

Systemd guidelines architectural decisions to be made
by Toshio Kuratomi 08 Mar '11

08 Mar '11

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

2 2

Glabels package v3.0
by Mario Blättermann 07 Mar '11

07 Mar '11

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

2 1

Question about missing CGI.pm
by Mike Ramirez 06 Mar '11

06 Mar '11

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.

2 1

RFC: No longer split out Elisp source into sub-packages
by Jonathan Underwood 05 Mar '11

05 Mar '11

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.

1 0

RFC: Update to XEmacs packaging guidelines [(x)emacs-filesystem]
by Jonathan Underwood 05 Mar '11

05 Mar '11

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.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging March 2011