packaging January 2009

packaging@lists.fedoraproject.org

46 participants
33 discussions

Squeak and Etoys packages
by Gavin Romig-Koch 21 Jan '09

21 Jan '09

This is some background information about the Squeak and Etoys packages. The Etoys package is an important part of the XO software that we are trying to move into Fedora, and Etoys depends on Squeak. I've just submitted for review (BZ481056) the first of three packages that make up the Squeak and Etoys packages that I've been working on. I'll submit the other two packages for review as soon as I finish this note. There has been some issues with these packages in the past, in part licensing issues, in part because Squeak and Etoys are somewhat different than anything else. The licensing issues have been resolved, these packages are now under Fedora acceptable licenses. This email is an attempt to address the other issues. This is very long, for which I apologize. I've tried to be through, perhaps too much so. If I can answer any questions, please ask. I think it is useful for anyone reviewing the Squeak and Etoys RPM packages to understand the high level organization of Squeak and Etoys. It is possible that these packages may require some exceptions to the Fedora Packaging Guidelines. Squeak is an implementation of the Smalltalk-80 programming environment. Like most Smalltalk implementations, Squeak is not just a programming language, but also contains a set of software development tools for editing, understanding, documenting, storing, and distributing Smalltalk source code. Squeak is implemented as a virtual machine/image pair. The Squeak virtual machine is analogous to the Java virtual machine in that in both cases they are native host programs which implement a virtual machine specific to the language in question. One major difference between the Squeak and Java virtual machines is that whereas the Java virtual machine loads a set of ".class" files which were compiled from Java source code stored separately in native 'text' files, the Squeak virtual machine loads a single Image (a squeak virtual machine image) which contains both the Squeak source code and the compiled (byte) code that runs on the Squeak virtual machine. Squeak source is stored in, edited in, distributed between, and compiled from and into an image file running in a Squeak virtual machine. While it is possible to write Squeak source code out to a native 'text' file, this is not commonly done, and not the way that Squeak source code is typically edited or distributed. The standard Squeak image contains all the source code for itself, as well as all the tools one typically uses to create and edit programs (editors, compilers, source code control, search and diff, change distribution, ...) built into itself. To get Squeak running, one needs both a Squeak Image (an image) and a Squeak Virtual Machine (a vm). There is a 'standard' Squeak image distributed by the Squeak project. It is the image that most people use when running Squeak. Like all Squeak images it contains both the source and compiled (bytecode) forms of the code in that image, and is the expected way that one views and edits Smalltalk source code. There are also a number of other Squeak images distributed for specialized purposes. Etoys, for example, is a specialized Squeak image, as well as some wrapper shell scripts to make starting it easy. The squeak-image SRPM and RPM contain the "standard" Squeak image distributed by the Squeak project. This image is installed under /usr/share/squeak, and copied into directories owned by users user when the user starts Squeak for the first time. As stated above, the Squeak Virtual Machine (vm) is a native host program which loads and interprets the bytecode within a Squeak Image. The source for the vm consists of two main parts: the core interpreter, and a large set of plugins which provide the core interpreter with access to OS and environment specific features (like X, GStreamer, and DBus on Linux). The core interpreter is written in a restricted form of Smalltalk and maintained and distributed using the standard Squeak software development tools. The plugins are written in C and maintained and distributed as C source files typically are. The core vm is compiled from the restricted Smalltalk into C, this compiled C code for the core interpreter is combined with the plugins, and this combination is what is distributed by the SqueakVM project, and is what most people use as the source for building the Squeak vm. While it is possible to create a Squeak VM from from the original restricted Smalltalk stored in the Squeak image, it requires a working Squeak VM to build a new Squeak VM from those original sources. The squeak-vm SRPM contains the source distributed by the SqueakVM project, and that is compiled into the squeak-vm RPM. In preparing these packages, I have come up with several ways in which these packages may fall outside the Fedora Packaging guidelines. The first is that its possible that the "No inclusion of pre-built binaries or libraries" rule applies to the Squeak images included in both the squeak-image SRPM and RPM. My understanding of this Guidelines is that it is meant to apply only to executable binaries which does not include the Squeak image. Even if my understanding is not correct, the Squeak image contains both to source and compiled forms of all of the code it contains, and is the natural form in which Squeak/Smalltalk programmers work with Squeak/Smalltalk code. A second way in which these packages may fall outside the Fedora Packaging guidelines is the fact that the source code for the core interpreter part of the Squeak VM included in the squeak-vm SRPM is not the original restricted Smalltalk source for this code, but is instead the C source code created by compiling this original restricted Smalltalk into C. While I could not find a guideline explicitly forbidding this, it is possible that this could be outside the spirit of the guidelines. To be clear the source included in the SRPM _is_ the source distributed by the upsteam project, it's just not the original restricted Smalltalk source for the core interpreter. I've packaged it this way for several reasons. First, compiling from the original restricted Smalltalk to C requires a working Squeak system - a chicken and egg problem. Second, all existing Squeak distributions compile the Squeak VM from the C source; if Fedora were to build it's Squeak VM from the original restricted Smalltalk there is a small chance that the built Squeak VM might be incompatible with other Squeak VMs. I felt that, particularly for our first official release, we should minimize this possibility. Finally, while the upstream SqueakVM project does distribute the original restricted Smalltalk code for the core interpreter (in a specialized Squeak image), and the needed tools and instructions for building the C source from this Smalltalk source, they are not yet rigorous enough in their release process to insure that the C source produced from these images is exactly the same as the C source they distribute. Because everyone uses the C source they distribute (unless the explicitly want to build a non-standard VM), the needed rigor has never been a priority. For these three reasons, I ask the Packaging Committee to either decided that that this is not a violation of the Guidelines, or grant an exception for this case. A third way these packages may fall outside the guidelines is that the Etoys package uses locales, but does not use find_lang. The Etoys package puts it's local files in .../share/etoys/locale/..., but the find_lang macro (as of F9) only looks in .../share/locale/.... I do not know if this a a find_lang bug (find_lang should be looking in more places) or a Etoys bug (etoys should not put it's locale files in it's own special special place), and I have not taken the time to figure out which. I'm sorry. If someone can tell me which is wrong, I'll see about getting it fixed. Of course these packages fall outside the guidelines in other ways through my failure to understand or implement them correctly, but these are the ways that I'm currently aware of. I've run rpmlint on the spec files, the srpms and rpms. There were three warnings I felt I could not or should not 'fix', they are documented in the BZ. -gavin...

1 0

Emacs add-on packaging and triggers
by Jonathan Underwood 20 Jan '09

20 Jan '09

Hi, The current (X)Emacs add-on packaging guidelines cover how to package add-on packages for (x)emacs, such as things like AuCTeX, Muse etc. These guidelines also cover the situation where a package Foo has a few Emacs helper files (eg. which add a mode to emacs to be used with the main package) - presently the guidelines stipulate that the emacs files are placed in a sub-package, emacs-foo. For example, the main gnuplot package creates a sub-package called emacs-gnuplot containing the files to enhance editing of gnuplot input in Emacs. Other examples include emacs-git, emacs-mercurial etc etc. It is this sort of situation that this present email is concerned with i.e. where a package is not principally an add-on for Emacs, but adds some elisp support files for the program. When I was drafting the guidelines there was a different practice that I wasn't aware of at the time whereby the elisp files are packaged with the *main* package (i.e. not an emacs-foo subpackage) and triggers are used to create symlinks to these files in the Emacs tree when/if Emacs is installed. Amongst other things, this negates the need for the package to have Emacs as a dependency. Examples include rpmdevtools, maxima and others. Briefly, this strategy is schematically below for a single file. I'm not using %_datadir etc macros for clarity: %install ... install foo-mode.el %{buildroot}/usr/share/foo/emacs/foo.el install %{buildroot}/usr/share/emacs/site-lisp{,/site-start.d} ln -s %{buildroot}/usr/share/foo/emacs/ %{buildroot}/usr/share/emacs/site-lisp/foo ... %triggerin -- emacs-common if [ -d /usr/share/emacs/site-lisp ]; then rm -rf /usr/share/emacs/site-lisp/foo ln -sf /usr/share/foo/emacs /usr/emacs/site-lisp/foo/ ||: fi %triggerun -- emacs-common if [ $2 -eq 0 ]; then rm -rf /usr/share/emacs/site-lisp/foo ||: fi %files ... %ghost /usr/share/emacs/site-lisp .... I've simplified the above for clarity just to convey the essence of it, and obviously the same strategy applies to xemacs. Also I've skipped any byte compilation details. One of the things that should jump out at you is that every package adopting this strategy will own /usr/share/emacs/site-lisp - a directory owned by the emacs-common package. The key question is: do we want to be allowing this strategy verses the alternative of having a separate emacs-foo subpackage? On the plus side it allows the user to not have to go hunting to install an emacs-foo add on package after she's installed foo in order to get emacs support working. And it manages to do this without the package foo pulling in Emacs. On the negative side it uses triggers, and is (in my opinion) more complex than a separate sub-package. Nicholas Mailhot in a discussion related to this issue voiced concerns that "triggers are very difficult to maintain and master long term since it's code from one package that fires when another package is installed with not warning, making install logs useless to understand problems."[1] I'd like to get opinions on this issue with a view to drafting a change to the emacs add-on packaging guidelines IF this strategy is considered acceptable. On the other hand, if this sort of thing isn't acceptable I'd like to help fixing the packages which do use this strategy presently. Right now, I personally have mixed feelings about it, and I would very much welcome other thoughts. Best wishes, Jonathan. [1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00186.html (and other messages in the thread).

2 2

RFC: revision of Haskell Packaging Guidelines
by Jens-Ulrik Petersen 20 Jan '09

20 Jan '09

Hi, I would like to solicit comments on the revised Haskell Packaging Guidelines, which have been updated and fixed a fair bit since the initial draft was first approved. https://fedoraproject.org/wiki/PackagingDrafts/Haskell cabal2spec which packages the latest packaging templates and generates spec files from haskell packages is currently under review: https://bugzilla.redhat.com/show_bug.cgi?id=479803. The new draft has been used successfully to review several packages now recently and older packages are mostly up-to-date with them too. If there are no obvious serious flaws then I would like to submit the revision to Fedora Packaging Committee for review. Thank you, Jens Petersen

1 0

Missing example text on Packaging/LicensingGuidelines
by Todd Zullinger 18 Jan '09

18 Jan '09

It seems that some text went missing from the example on multiple licensing scenarios during the wiki conversion. Compare: https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licen… https://fedoraproject.org/wikiold/Packaging/LicensingGuidelines#line-79 The text in the example should be more like this: # The entire source code is GPLv2+ except foolib/ which is BSD License: GPLv2+ and BSD -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It's not denial. I'm just very selective about what I accept as reality. -- Calvin ("Calvin and Hobbes")

2 1

Reviewing explicit Requires
by Michael Schwendt 18 Jan '09

18 Jan '09

Hi everyone! Because of broken dependencies in an update declared as stable, I've run into package "condor". It's a 20K spec file with a remarkably short review ticket, and I wondered why it contains the following explicit dependencies? Requires: pcre Requires: postgresql-libs Requires: openssl Requires: krb5-libs Requires: gsoap Requires: mailx Actually, all of them except for "mailx" are added automatically by rpmbuild already (as dependencies on SONAMEs): http://koji.fedoraproject.org/koji/rpminfo?rpmID=948426 I've double-checked with the current ReviewGuidelines, and I could not find a corresponding entry that would make reviewers block such explicit dependencies. If memory serves correctly, we've had a section somewhere in the Wiki. Searching further, I've found only https://fedoraproject.org/wiki/Packaging/Guidelines#Requires which only says RPM has very good capabilities of automatically finding dependencies for libraries and eg. Perl modules. In short, don't reinvent the wheel, but just let rpm do its job. There is usually no need to explicitly list eg. Requires: libX11 when the dependency has already been picked up by rpm in the form of depending on libraries in the libX11 package. and which is linked from the review item MUST: The package must meet the Packaging Guidelines . The phrase "there is usually no need to" is vague without any emphasis like SHOULD/MUST and no specific entry in the review guidelines. Does anyone remember where the paragraph has gone, which commented on the badness of explicit dependencies on package names?

2 2

Packing Hadoop
by Fabian Deutsch 17 Jan '09

17 Jan '09

Hello, I'm quite new to packing up packages for Fedora. It might not be the simplest package to create, but I quite like hadoop and wanted to package it up, so it's easier to maintain on Fedora based boxes. There are a couple of issues I ran into: - Can I explicitly require a java package not just to be installed, but also to be the the selected alternative? (openjdk ist required at build- and runtime) - Where to put those jars? I'm suggesting /usr/share/java - What about missing dependencies? There are some jars required which are not packed up in Fedora yet. I'm not allowed to use the binary-jars distributed in the hadoop tarball? - Scripts There are scripts to run hadoop and dfs (bin/start-all, stop-all, ...) Where shall I put them? Create a custom user, as postgres does? Maybe someone can share experience to solve this issues .. - fabian

2 2

Confused by non-numeric version in release guideline
by Richard W.M. Jones 15 Jan '09

15 Jan '09

This package just numbers their tarballs using the subversion release number. For example, 'r8' and 'r11': http://code.google.com/p/dlfcn-win32/downloads/list As far as I'm aware they are not planning on using "real" version numbers at any time in the future, nor have they used real version numbers in the past. I don't understand which if any of these guidelines apply to this case: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease In particular, what should the Version be? (And while we're at it, what should the Release be?) Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v

11 32

Java packaging of Bluecove
by François Kooman 15 Jan '09

15 Jan '09

Hi, I'm trying to package Bluecove (a Java stack implementation of JSR-82) using BlueZ [1]. Upstream has two tars: (bluecove-2.1.0-source.tar.gz) which contains everything needed for platforms like Windows and OS X (Apache 2 license), and for Linux a separate tar (bluecove-gpl-2.1.0-sources.tar.gz) that contains some BlueZ JNI foo (and which is GPL licensed). Does it make sense to put this all in one spec file/package? Bluecove without the "gpl" part is useless on Linux. It would probably be cleanest to just have one spec file and one package that includes the jar file and the native library? But this would require fiddling with Source0 and Source1 and some setup macros. Are there any examples of this? Any advice? Thanks, François [1] http://code.google.com/p/bluecove/

5 5

Re: [Fedora-packaging] Draft vote on Font Package Naming
by Jens-Ulrik Petersen 15 Jan '09

15 Jan '09

----- "Tom \"spot\" Callaway" <tcallawa(a)redhat.com> wrote: > The draft is available here: > http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_% > 282009-01-13%29 Sorry but this is not a good idea IMO. It requires 119 binary font packages in rawhide to be renamed, a number of which are referenced by a number of other packages in the distro. It also makes it hard for people to work out what the source package name is. What is so bad about the current fonts package naming convention "name-fonts-face"? Jens

3 5

Re: [Fedora-packaging] Draft vote on Font Package Naming
by Nicolas Mailhot 15 Jan '09

15 Jan '09

Le Jeu 15 janvier 2009 00:53, Jens Petersen a écrit : > > ----- "Tom \"spot\" Callaway" <tcallawa(a)redhat.com> wrote: >> The draft is available here: >> http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_% >> 282009-01-13%29 > > Sorry but this is not a good idea IMO. BTW I think Jens objects strongly because he did not see some of the horrific naming changes FPC proposed first, which would have resulted in mass srpm renames and totally un-obvious srpm name -> rpm name mappings. (and we use srpm names to reference packages in all our infra tools) The current FPC-approved draft is a lot saner and does not require too much implementing work I think: 1. it does not change existing font srpm names at all, except for - the handful of packages that didn't respect strictly the previous semi-official naming guidelines (I write semi-official because even though no explicit font naming guideline was written down a naming style was suggested in official font spec templates) - the handfuls of packages which didn't use foundryname prefixes when they could (and we'd planned to make them change them anyway since having some packages with this prefix and others without was confusing to users and packagers) 2. does change font subpackage names slightly for font subpackages of font srpms. I've pushed a new fontpackages-* rpm set (templates and macros) to rawhide that minimizes the changes needed to existing font specs to adapt to FPC naming (only %package and %description lines) Of course packagers will still have to add Obsoletes manually, plus some sort of Provides transition for the few font packages that other packages depend on Actual subpackage content and internal file layout didn't change. 3. Clarifies the font subpackage naming for font subpackages of non-font srpms. Well since there was no clear convention before, and inconsistent naming practices, any clear naming guideline was going to require changes in most packages. I've adapted the macros to force the FPC naming rules in that case. WARNING 2. and 3. mean that trying to rebuild a srpm with font subpackages in rawhide without doing the small spec changes entailed by the new naming rules adopted by As a test I've rebuilt a few font packages on my system, and changed bitstream vera in rawhide, to verify it works in koji (it does), and to provide people an example of what the renaming entails in practice for a non-trivial font package. Sincerely, -- Nicolas Mailhot

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging January 2009