|
 |
| Fri, May 16th | home | browse | articles | contact | chat | submit | faq | newsletter | about | stats | scoop | 17:12 PDT |
|
|
login « register « recover password « |
|
| [Article] | add comment | [Article] |
|
| Theme topics | Apps | Resources | Window Managers | Afterstep | Blackbox | Enlightenment | Fluxbox | GTK | IceWM | KDE | MetaCity | Sawfish | Window Maker |
|
|
|
This article records our experiences with packaging an application for many distributions and shows areas in which packagers, Linux distributions, and developers can improve coordination for better and easier distribution. We look at communication problems, packaging errors, package dependencies, menu entries, and bug tracking systems. Copyright notice: All reader-contributed material on freshmeat.net is the property and responsibility of its author; for reprint rights, please contact the author directly. On packagingFor Free Software, more users means more potential developers. With tvtime, we made an effort to ensure high quality packages for all major Linux distributions. This article describes some of our findings when packaging for ALT Linux, Debian GNU/Linux, Gentoo Linux, Mandrake Linux, Red Hat Linux, Slackware Linux, and SuSE Linux. We present some of the lessons we learned and some of our assumptions that we found to be false. We believe our project is typical in that it is fairly young and unknown, and so we believe that many other developers and packagers may benefit from these notes. Packager-developer communication is poorWe originally thought that finding packagers for our application would be difficult. However, we soon discovered that packages were being made, but we were rarely notified. While some of these packagers had just built RPMs for their own personal use, we found that many had made packages which they provided to the community or contributed to their distributions. Our Mandrake packager explained that he never contacted us because he never had any problems with our package. Our advice to application developers:
For packagers:
The lack of email messages or other notifications from packagers was by far our most surprising observation, and we believe that this issue deserves more awareness. While many packagers have assured us that they usually do send an email to the developers, we hope that developers will make package searching a part of their own QA process. References:
Errors in packagingWe have learned to watch for some specific errors in the packages during a new release of our software. We believe that these issues are usually noticed more easily by the developer than the packager. Developers should:
Dependency problemsA problem for packaging any program is how to handle non-standard dependencies. There were three main problems we encountered:
Clearly, there is never an ideal solution for these sorts of problems, and it's hard to give advice about what to do with them. We do not believe that the responsibility for these sorts of difficulties can lie completely with the packager. We believe that applications themselves can often be improved by having runtime (vs. compiletime) options and even by avoiding dependencies that are problematic for users. However, in order to make these judgements appropriately, feedback is required from packagers on multiple distributions. Menu entries and .desktop filesThe most common thing that packagers of tvtime added to our packages was a menu entry or .desktop file. We discovered that by consolidating the combined input from our packagers, we could help ensure that our menu entries had a similar look and feel across distributions and menu systems. The .desktop file formatThe desktop entry file format standard is used by both GNOME and KDE for their menu entries. However, installation locations and conventions for both the .desktop files and associated icon files have not been standardized until recently. freedesktop.org is leading this effort with standards for menu entries and how applications can locate them. This standard is used in KDE 3.2 and GNOME 2, but the rollout of these systems is not yet complete. We found that understanding what standards exist and how we should use them was quite challenging. Where should the .desktop files be placed by a .spec file or Debian installation script, do we need to install them separately for a GNOME or KDE setup, and how is this affected by user upgrades? We lacked any Best Current Practices information from desktop environments or distributions. Here is a list of where we decided to place our .desktop files and icons for installation on modern distributions. We don't believe this list is sufficient and would like to expand it to include more common cases.
References:
The Debian menu systemDebian created its own menu format for applications which predates the freedesktop work. This menu format is also used by Mandrake, but it is slightly modified. ALT Linux uses the same modified system from Mandrake. The format is simple, but less powerful than .desktop files. The most notable disadvantage of this format is the lack of internationalized names. Our entry for Debian is:
?package(tvtime):needs=x11 section=Apps/Viewers \
title="tvtime" command="/usr/bin/tvtime" \
icon="/usr/share/pixmaps/tvtime.xpm"
For both Mandrake and ALT Linux, we use:
?package(tvtime):needs="X11" section="Multimedia/Video" \
title="tvtime" command="/usr/bin/tvtime" icon="tvtime.png" \
longtitle="High quality television application"
The section titles are completely different between Debian and Mandrake. For our application, a TV viewer, the Mandrake sections are much more descriptive. Also, it seems that Debian requires icons in the xpm format. Since the freedesktop initiative is so promising, these legacy menu systems may soon disappear, so we recommend that maintaining these menu entries be done by the Mandrake and Debian packagers. However, we strongly recommend that the upstream ensure that both the Mandrake and Debian menu entries are as close to each other as possible. References for these files from Mandrake and Debian are here:
Hearing about bugs and dealing with themProbably the most difficult problem for users and developers alike is the handling of bug reports. This includes both bugs in the application and in the packaging. We found only Debian to provide us a method of automatically receiving all bug reports for our application (through http://packages.qa.debian.org/ and the package tracking system). However, Red Hat does allow you to subscribe by maintainer. Many believe that the distribution QA infrastructure should provide the first level of tech support in all cases, and users should always be instructed to seek support first from their distributions. We believe this is irresponsible. Most packagers and distribution QA teams, like developers, are volunteers with time constraints, and application developers need to be aware of packagers and their packages since they will likely have to help support them. We would like to see packagers inform developers about the user experience of their packages. At minimum, we would like to know:
This information can go a long way towards helping developers provide better support for their applications. References:
ConclusionWe have presented some of our experiences in packaging our application and consolidating our user experience across many Linux distributions. We hope this will help packagers, distributors, and other developers be more aware of the problems and possible solutions for distributing Linux software effectively. We also believe that packagers can do more to tell developers what might make their jobs easier. We found that through a small amount of coordination, we could consolidate some common additions done by different packages, reducing work for the packagers. We believe that this significantly reduces the number of distribution-specific bugs. AcknowledgementsOur thanks go to Oliver Baltzer, Mike Harris, Sam Hocevar, Max Kalika, Simon Law, David Lehn, Guillaume Rousse, and Matt Zimmerman for their comments on this document. Author's bio: Billy Biggs is a 'leet haxor who spends too much time on tvtime. His homepage is at www.billybiggs.com. Doug Bell is also 'leet, and plans to spend more time on tvtime. He can be reached at drbell@users.sourceforge.net. T-Shirts and Fame! We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about. [Comments are disabled]
[»]
Dependancy Issues A lot of dependancy issues will magically go away when you compile your
binaries as static.
[»]
Re: Dependancy Issues
[»]
fogoten Distribution Another well-known distribution that was not mentioned in the article is ROCK Linux a disrtibution build kit with predefined distributions. We automatically generate dependencies - and defined a rock-registry where custom .desktop files are placed to generate common menues for any window-manager / desktop environemtn you need.
[»]
One thing I'd love to add to RPM....... And it would have a tremendous affect on the ease of building cross,rpm
based, distiribution packages. A logical or. Right now if say RedHat
calls it libFoo, Mandrake has libfoo and libfoo-devel and SuSE just has
libfoo then you can't build a single rpm. but if you could say.
[»]
Re: One thing I'd love to add to RPM.......
--
[»]
Re: One thing I'd love to add to RPM.......
[»]
DeMorgan to the rescue?
[»]
Re: DeMorgan to the rescue?
[»]
Packaging, an alternative perspective The concept of packaging, in an environment which is highly fluid, may actually be a mistake. I am going to propose an alternative view, which might address some of the problems currently facing packaging systems. Instead of specifying a directory tree, specify file groupings. Have the destination of those groupings be decided by the installer software or installee. That way, you don't have the issue of incompatiable installation trees - the tree will always be (by definition) compatable with the user's preferred structure. Instead of specifying file permissions, specify file natures. MIME types should be adequate for the job. After all, you don't know what permission system is being used. Standard UNIX? POSIX ACLs? Trustees ACLs? MACs? Since the "package" builder doesn't know, they can't tell the package exactly what setup to use. All they can do is describe what they want. The installer software needs to be able to parse that description into something usable by the permission system that is installed. Dependencies are a huge problem with packages, partly because absolute version numbers are used, or minimum versions, or no versions at all. Nor is any information included on how to meet those dependencies adequately. (eg: You might need PHP 4.1, but do you say what modules are required?) It's no use filling the dependencies on first match, either, because of the configuration issues. You need to parse ALL dependencies, decide what the COMPOSITE requirements are, and then (and only then) actually try to resolve those requirements. However, you've still got the problem that those requirements may be dependent on each other, too. You must therefore gather all of the required components, determine THEIR composite requirements, and repeat, until a complete picture has been assembled. This must also be matched against requirements of existing software, so that you don't break a pre-existing dependency. Only after all these stages are you ready to install/build the necessary components, in the necessary order. Incompatiable requirements can be resolved, by various means. One method is to use group permissions. Create assemblies of packages, and then use group permissions to split the complete collection of packages into compatiable sub-collections (ie: the assemblies). eg: Program A is required by program B, but conflicts with program C which is required by program D. Put A and B in the same group, C and D in the same group (but different from A and B), then set A and C to be group executable but not world executable. (Or, if you're using ACLs, simply ensure A and C are never on the same list.) Although you can resolve certain incompatibilities using the above method, it has its limits. The package software and package maintainer must therefore place certain constraints on conflict resolution, and define actions if those constraints would be violated. eg: Is the package to be installed, or is the conflicting package to be removed? Once you've built up a system for handling revision control, conflict resolution and dependency resolution, you've got a packaging system that's actually worth using. Until then, it will always be possible to package things up correctly, and yet still produce badly broken results. In today's day and age, that should not be acceptable. We've more than enough resources to handle all possible contingencies in a controlled, robust manner. But, hey, there's always the case that that wouldn't be nearly as fun as the chaos.
[»]
Re: Packaging, an alternative perspective
--
[»]
Mandrake wiki The mandrake rpm howto is now hosted on the mandrake wiki. http://qa.mandrakesoft.com/twiki/bin/view/Main/MandrakeMenu
[»]
Fedora www.fedora.us have a really good packager community , atleast for RedHat.
Check it out.
[»]
The obvious solution..... ... is to have developers build their own packages, which are the official
way to install the software. The team that wrote the software are the best
qualified to package it anyway.
[»]
Re: The obvious solution.....
[»]
Re: The obvious solution.....
--
[»]
mandrake menu system check your facts, the mandrake menu system is internationalized.
[»]
Re: mandrake menu system
[»]
Lessons in Packaging Linux Applications Very good, but I noticed you didn't even touch on the issue of proper file
and directory access permissions and security considerations. I think this
is obviously important and needs to be considered by any and all package
builders and developers also. --
[»]
Re: Lessons in Packaging Linux Applications
You are right, it would have been useful to touch on this subject. I have not seen many permissions problems across distributions, except for the directory in /var/run we create to place our FIFOs, much like screen would use (although it is an interesting exercise to see where screen's FIFOs are placed in different distributions). This directory should be group writable by any users that run tvtime, usually anyone that can access the /dev/video devices. Getting these permissions correct was another part of the packaging where we have found errors.
[»]
Re: Lessons in Packaging Linux Applications
--
[»]
Re: Lessons in Packaging Linux Applications
Have you seen http://checkinstall.izto.org? I
use it to create my own debian
packages: ./configure; make; make install
and you have a .deb package. The nice thing is you
can add dependencies to them, and last time I
upgraded with apt-get upgrade, my custom
made packages were replaced correctly with new
binary versions that were available.
Really fantastic. Do get the development version
for dependencies and other advanced uses which
still have not made it to the stable branch.
[»]
Re: Lessons in Packaging Linux Applications
[»]
Re: Lessons in Packaging Linux Applications as you know...my favorite distro is redhat. may be it is sound subjective
because i've used it since 1998 and it's very user friedly. Package is
very interesting thing, because for me, choosing an approriate OS,
sometime can be see when we do the installing. I think, if the distro
make the package simpler and easier, alotof people will choose it. And
that what microsoft do the best. :P. if linux can make it, wow, the great
OS with Great installer, it will make linux really unbreakable.
|
|
