The Universal Source Package
 by Bud P. Bruegger, in Editorials - Sat, Feb 12th 2000 23:59 PDT

Bud Bruegger writes: "This paper discusses the need for extending the philosophy of GNU autoconf into the world of package management. Such an extension could be seen as a 'universal source package' standard and tools. It was written with the hope of stimulating a discussion on the feasibility of such an approach."

GNU Autoconf Solves Only Part of the Problem

Most open source software runs on a wide variety of UNIX-like platforms. To make life much easier for software authors, and as a great incentive to write multi-platform software, the GNU Project created Autoconf, which makes it possible to easily compile and install software on a multitude of platforms -- or does it?

Well, it does a great job for compilation and also for installation if we install the software manually (eg., using make install). But considering that the majority of installations use comfortable package management tools, autoconf really covers only the first part of the needs. It does not address the problem of packaging the software for a wide variety of package management systems.

The number of package management systems is very large, and it is neither possible nor desirable to standardize on a single one. This means that a multi-platform program has to be packaged in many different package formats -- an enormous effort!

The similarity of compilation environments that autoconf relies on to address the multi-platform problem seems to be very similar to the similarity between various package formats: there are slightly different ways of achieving the same goal. (While it is true that different package management systems may differ in their functionality, the similarity is still there in all supported functional areas).

The Duplication of Effort for Packaging

Let's look at the social cost of this. Assuming that packaging for different systems is really similar, an enormous amount of effort goes into doing highly similar tasks. This is a serious concern, since users are constantly faced with problems such as software that does not exist pre-packaged, or packages being out-of-date or lacking important security fixes.

I believe that a lot of valuable resources are wasted by this tremendous duplication of effort. Applying the open source philosophy of reusing and sharing to packaging could free resources that could be used to:

• Greatly increase the choice of prepackaged software.
• Do a better job of keeping packages up-to-date.
• Look into related problems such as the design of package tools that allow central administration of large clusters of machines (see, for example, http://www.beowulf.org/ or http://www.infrastructures.org/).

The Universal Source Package as Solution

The solution to the problem seems to be to extend the autoconf approach to package systems. This requires providing the necessary tools, standards, and guidelines to software and/or package authors to enable a single source package to produce a wide variety of binary packages for the various platforms and packaging systems. Even for someone who wants to compile all software by hand, the consistency of a standardized source package makes this job much easier, faster, and less error-prone.

While there are some efforts in this direction, I believe they are too limited:

• Alien ( http://kitenet.net/programs/alien/) operates at a binary level and is thus inherently limited to a single platform.
• EPM ( http://www.easysw.com/epm/) seems to be a great first step, but I believe that the solution of the problem requires a somewhat wider problem definition to maximize effect and that, in order to be successful, an organizational effort of standardization has to go along with the technical effort of development.

Components of the Universal Source Package Approach

What should a potential project on universal source packages produce? The following list of components is not meant to be comprehensive or even thought through in detail; it is rather meant to give first ideas of what may be needed to achieve the goal:

• Specification of a universal source package format.
• Tools to help build such packages (that can be ported to multiple platforms).
• Tools to build binary packages for multiple architectures, base-OSes, and distributions from this single source. (EPM may do some of this already.)
• An API that abstracts platform/distribution specifics that has to be used in pre- and post-install scripts (how to start and stop daemons, how to register a cron job, how to get logs automatically managed, etc.)
• A universal API to be used by original authors that covers things such as logging, management of configuration data, etc. (Note that this opens the way to new system administration tools that are simply too complex with the current diversity of approaches).
• Platform/distrib/language-dependent implementations of these APIs
• Backends for the configuration management (XML files, central LDAP, DBMS, interactive Qs, etc.) based on these APIs (similar to Debian's debconf).
• Guidelines for original authors.
• Guidelines for universal package authors.

Conclusions

While competition in the field of package management tools is unavoidable and perhaps even desirable, effort duplication during packaging seems undesirable and causes an unnecessary limitation of the availability of packaged open source software today. Just as autoconf addresses the multi-platform issue in the domain of the software author, source-level packaging seems to be best dealt with there.

It is the author's belief that the time is ripe to start working on a universal source package system. While the effort required for such a project is considerable, the enormous benefits it promises may make it well worth while.

Bud P. Bruegger (bud@sistema.it) received a Ph.D. from the University of Maine in Geographic Information Systems in 1994. His company Sistema (www.sistema.it) develops information systems for customers such as FAO (www.fao.org). The idea of universal source packages grew out of a discussion about managing infrastructures (large clusters of computers of different UNIX flavors) on the mailing list of www.infrastructures.org.

T-Shirts and Fame!

We're eager to find people interested in writing editorials 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 editorial gets a freshmeat 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]

Referenced categories Topic :: System :: Archiving :: Packaging Topic :: System :: Software Distribution Topic :: System :: Software Distribution Tools

Referenced projects Alien - Converts between the rpm, dpkg, stampede slp, andslackware tgz file formats Autoconf - A package of M4 macros to produce scripts to automatically configure sourcecode. EPM - A software packaging tool.

 Comments

[»] We need a good modeling of the package structure in source
by nekrad - Apr 23rd 2004 17:43:50

I'm doing some research on a completely different approach:

Instead of writing rules for building software and then writing
rules about how these rules should be written by the machine
(well, that's in fact what autoconf does!), we need go in from
another side: tell the machine just the (abstract) structure of
our software.

Most packages can be modeled in a tree-structure of nodes like
libraries, modules, executables, sources, manfiles, etc.
We give our buildsystem just the information which makes our
software individual, thus listing the executables, sources,
libs, etc.

Here's a little example i've posted to xouvert-general today:
(this could be an XML representation of the "bitmap" applet)

<PACKAGE class="xwindow:applet" name="bitmap">
<EXECUTABLE name="bitmap">
<IMPORT type="library" name="Xaw"/>
<SOURCE name="BitEdit.c"/>
<SOURCE name="CutPaste.c"/>
<SOURCE name="Graphics.c"/>
<SOURCE name="ReqMach.c"/>
<SOURCE name="Bitmap.c"/>
<INCLUDE name="Dashes" class="xbm"/>
<INCLUDE name="Down" class="xbm"/>
<INCLUDE name="Excl" class="xbm"/>
<INCLUDE name="FlipHoriz" class="xbm"/>
<INCLUDE name="FlipVert" class="xbm"/>
<INCLUDE name="Fold" class="xbm"/>
<INCLUDE name="Left" class="xbm"/>
<INCLUDE name="Right" class="xbm"/>
<INCLUDE name="RotateLeft" class="xbm"/>
<INCLUDE name="RotateRight" class="xbm"/>
<INCLUDE name="Stipple" class="xbm"/>
<INCLUDE name="Term" class="xbm"/>
<INCLUDE name="Up" class="xbm"/>
</EXECUTABLE>
<EXECUTABLE name="bmtoa">
<SOURCE name="bmtoa.c"/>
</EXECUTABLE>
<EXECUTABLE name="atobm">
<SOURCE name="atobm.c"/>
</EXECUTABLE>
</PACKAGE>


I've set up a mailing list for my project, which I've called
"treebuild". You can subscribe via majordomo's mail interface at majordomo@metux.de

regards
--
E. Weigelt, CEO, metux IT service == http://www.metux.de/
--
Software-Patente töten Innovation und entrechten Autoren.
Stand up for your rights! == http://www.softwarepatente.com/

--
http://wiki.metux.de/public/OpenSource_QM_Taskforce

[reply] [top]

[»] Another project
by spiderbox - Feb 3rd 2003 21:06:16

How about this?:

uPM - The micro Package Manager

http://u-os.org/upm.html

[reply] [top]

[»] From another direction..
by lithos - Feb 16th 2000 14:13:04

Spaceman Spiff you may be right, the only problem is I've hit resistance like that before. And although I really like to be the nice helpful guy, sometimes a nice sharp smack upside the head yeilds better results than being nice (frightingly so).

On the topic of bringing together all the unified, etc.. packing discussions the easiest way would be to start a mailing list. Depending on if you want a project from it or not you can go to www.onelist.com (just a mailinglist no project) or to www.sourceforge.net (mailing list, project, forum, etc..) Both are free and do a really good job.

Now to jump back from my pre-emtive flaming view with a unified package manager there need to be a few things laid out (all of them obvious, but I'll reiterate them anyway [go figure none of this stuff is really new])

Things needed from a Unified Package Manager (UPM) user perspective:
-Must be able to install a package with as few keystrokes/mouse clicks as possible.
-Installation should not require more than 12 steps to complete (and no sub-steps).
-You must be able to list what you currently have installed.
-You must be able to uninstall what you have installed.
-Configuration should be automatically run after the install.

Things that a UPM must do:
-Keep track of installed packages and their respective versions (I'd personally push for a standard versioning scheme across software eg: use the date)
-Needs to know if package xyz is a newer version of zyx and it's dependancies, or is it just a similar package.
-Have one format across systems.
-Have a set of API's such that the front end and middle ware can be different across platforms but the backend has strict guidelines.
-Have a set of tools so those who write software can easily package their software into the UPM format.
-Be able to install and uninstall packages across linux distributions.
-Should have installation rules (you must do things in this order *period*) such as check for diskspace before trying to install.
-Should have installation guidelines (suggested things but not manditory), things like a default installation path (that can be changed).
-Be able to resolve versioning/symbolic linking problems.. which libgl.so am I really using?

Things that need to be discussed/agree'd upon:
-Package format/organization
-API prototypes
-Rules and guidelines
-Etc..

One of the best ways to understand what is needed is to look at (gasp) windows, UPM must be better than the windows system (I'd really like when I uninstall things for the files and directories to really be removed).

Once things like this have been decided upon, then a spec can be made, then a working model.. Then whether or not the distribution maintainers want to use it, being nice and kind and asking those who write and distribute software to use it will make it a standard. But the foundation must be made first and shown to work. I know that with a good well rounded system that a few people from different software companies that I've conversed with would be very supportive of a UPM project and standard.

[reply] [top]

[»] Packaging is definitely a problem and a solution.
by Bill Pechter - Feb 16th 2000 11:42:00

I'm a big fan of the FreeBSD ports and packages method as mentioned above.

While it's a pretty good answer to the problem of keeping thousands of packages up to date and handling the installation of commercial software for Linux on *BSD -- it's not perfect and there are people looking to improve it.

I'd also like to see a package format and tools compatible with the commercial Solaris packages so software from commercial vendors can run under Linux and *BSD as well (since binary compatibility is possible within the same architecture).

Imagine a modified BSD ports makefile system that would make packages that could be installed by a Solaris-compatible pkgadd utility. We could also load Solaris compatibility packages with it.

Bill

[reply] [top]

[»] Additional RPM features (applies to other packagers, too)
by swingerman - Feb 16th 2000 09:40:57

All too often, RPM packages appear to rely on a particular package name as a dependency. This is fine if you are only using packages from one package vendor, but once you start to mix them, things can get ugly. The purpose of packages is to bundle up related components (docs, binaries, libs) into one file for easy distribution and installation. If you install a RedHat RPM of Mesa and you install a SuSE RPM of a program that needs Mesa to work, I have seen the combination of differing packagers fail.

Here is what I propose. Instead of each package listing other package names as dependencies, have an association between each package that is installed on a system and the capability or capabilities that it provides. This sort of association is potentially cross-distribution. We could set up some sort of central repository of what capabilities (from a joint-proposed name) exist on a system and what package provides it as a DBM-style database file. Each packager (deb, rpm, etc...) will be responsible for updating this database with its capabilities and reading it for capability conflicts.

This will work towards elimination of that all-annoying rpm --force -Uvh .i386.rpm by removing the dependence on a particular package naming scheme and replacing it with a joint-approved capability based setup. Tools could also exist to allow people to register the capability of software that they installed that didn't use a package managing system (.tar, for example). That way, if someone wanted to download and install Mesa by .tar and then install a package that required libGL.so, they could register that the Mesa.tar.gz provided the OpenGL execution capability, version 1.1. Then, when they went to install GLQuake.i386.rpm, the package manager would check it dependent capabilities and then happily install or alert the user if capabilities were missing. In either case, the user wouldn't have to rpm --force -Uvh each package that wanted the OpenGL execution capability, version 1.1.

Comments on this are solicited to jasonp019@yahoo.com.

Thanks!

[reply] [top]

[»] Metal-Box
by linux - Feb 16th 2000 04:15:06

Of all the discussion about Linux, I find it kinda troubling that there are TOO MANY place for us to place our discussion.

We can discuss it here, and then slashdot also has its own discussion forum, and then the usenet and all other private mailinglists.

If there is to be a concensus, we need to find a way to unite all the discussion domains together.

I feel like what has been discussed here is important and beneficial to all Linux users and future users as well. But it would be unfair to many if there is only some of us who have taken part in the concensus process.

My own proposal to the autoconf thing is to adopt the "Metal-Box" approach, that is, unless the user specifically wants to hand-tune his own system, make the Linux installation a "hands-off" event. That is, seperate out the user from the installation process - and let the system installs itself.

Perhaps before the "hands-off" process gets started, the users are greeted with the "What do you want" prompt, and a list of choices which the user can tick on and off.

Sounds like Windoze, you say?

Yes, but better. WIndoze needs to prompt the user to get "yet another driver" and in the fully automatic Linux installation process, all the required drivers are there, and if there are some drivers that are NOT available in the distro, then a URL is provided for the user to pull down the require driver.

Perhaps a unified URL for all Linux drivers is required to get that going.

What do you think?

[reply] [top]

[»] The *BSD ports system suggest a way out
by dirkx - Feb 16th 2000 03:29:12

If you look at the *BSD port's system, which is furthest developed on FreeBSD, you see such integration with the package management tools.

It works really quite well; and is quite refined over the years. The basic concept of a port is just a 'makefile' which
has enough info to fetch the source, apply patches where needed, and then do that package its config/make. The install is defered a bit and can be combined with a binary package creation. Things like rc.d startup scripts are usually included, as are things like adding a username or group to files in /etc.

One could argue that it is very silly that the BSD community does massive effords in keeping the PORTs updated for virtually every piece of downloadable code (OS, and non OS) and that their work stays limited to just that one OS. For a very limited amounth of extra work you could add a few other unixes.

Dw

[reply] [top]

[»] Whoa lil' doggy...
by Spaceman Spiff - Feb 16th 2000 00:10:10

To Lithos:

I think you jumped the gun there, pardner. Not a flame, just an observation. You are correct to point out that all casual users, and many of us geeks too, could benifit from a two step install, like you describe (1. Insert CD. 2. Click da button.) No argument there.

What I think Mr. Corbeau was describing, however, was the technical aspects of how such a system would work. So, after step 2 above, some script would run that uses make instal, or tar.gz, or whatever, to do the actual install. This to the programmer has advantages in that everyone already know how these tools work, and in fact the tools are already written. The Linux community just needs to agree on which tool(s) to use.

Ok. That's it. Just sounded like you may have mis-construed (sp?) the original post.

So really the first step is to: get enough people to agree that a unified installer is needed (not everyone, just enough for a workable quorum). If you don't get that, nothing will happen at all.

So who wants to send email to Red Hat? and Debian, of course and Suse and all the others and maybe folks like VA and IBM and maybe the BSD crowd as well (my prejudice, BSD is good folks, I like 'em).

Well? Stop readin' and starting emailin', y'all. :-)

[reply] [top]

[»] turn it inside out
by poiuyt - Feb 15th 2000 23:58:57

Lots of distribution have utilities (ie /usr/bin/install) that makefiles call to do parts of installs. Why not make an install-like utility that performs that action, but follows distribution-centric and evolving community standards for finding what to install? Check out this made-up description.

Usage: app [-iueb...] directory/tarball [-o[what]=[filename]]
Operation: the first option is -i install, -u update etc.
The second option specifies the source directory.
The third option is for making native packages ie [-orpm=foo.rpm],
or just -orpm

First, app scans the directory for meta-information files and consolidates it. The canonical meta-information file is meta.xml, following some DTD. Other meta-information files are %spec, etc.

For packages with no meta-info - most of the packages out there - the package is compiled using configure; make (with the user watching - ie user sees README, then is prompted for the compile command, defaulting to "configure; make")

Then app scans the files in the directory, compares it against the meta info, and ends up with lists of binary files, shared libraries, modules, plug-ins, icons, daemons, desktop menu categories, users (for subsystems like sendmail), log files, etc. etc. etc.

At this point, if app needs to ask the user, especially about where they want thier icons, whether they really want to place new files in /sbin, it can do so. Implementations of app need to *save the answer* to be used in future installs by the same sysadmin, to share compile setups between users and automate the building of native packages for distribution makers.

Then app does all the adding and copying and package building required by above.

--
Distributions could do implement this however they wanted. This could be a shell script on a floppy linux that does not actually understand any XML info or be a helper application for my web browser thats unpacks the tar.gz file, interact with the user via a fancy GNOME application. Distributions could make an "app" clone that had plugin capabilities for package formats (reading in place of "directory", and building)

The keys are:

- "app" does not mandate a package format or a directory structure. Well-defined and common ones formats/structures will inevitably be well-handling by each distributions' configuration of "app"

- all build processes should be in a sandbox. There should be one and only one piece of software responsible for getting the built files placed into the OS environment correctly.

- a log of installation should be reusable and possibly sharable.

[reply] [top]

[»] From Geek To User
by lithos - Feb 15th 2000 20:17:57

After reading the comment from the debian maintainer I started to feel a little sickened (no offence intended). I'm sure quite a few of you being here and reading this have wanted linux(s) to become the popular os, and the os of choice. Well I can reassure you that if you hold the same opinion as that debian maintainer it will never happen. Now instead of leaving it there let me expain why.
Why? When linux(s) is a OS that forces a user to become a geek to use it is too hard to use for the general populace. When linux(s) requires those who write software to create different distributions of their software based on installer or the fine intracacies of that version of linux it is too hard to release a product for it. Some of those who control what happens to the distributions (sadly most of the time it's the distribution maintainers) have lost sight of the reality of making a OS a product and not some fringe fad. When it takes more time to install and configure a product than the time it takes to make some coffee you have a problem (and no not you installing it, a newbie aka USER).
Lets take a example from that other os, where I can insert a CD and it autoruns, I can install with a few button pushes and let it go. Then I can use the program without fiddling with system configuations, I don't have to worry if this symbolic link is pointing to the right place, I don't have to worry if it's using glib5 or not, and I can uninstall it with three clicks of my mouse. Simply amazing isn't it? The user wants ease of use and linux isn't, the user wants to be able to go into a store and buy software as christmas or birthday present and not worry if it works on distributions A,B and C but not D through F.
The easiest way to accomplish this is through a UNIFIED package manager, that manages installation, configuration and removal. Now some may think that this is imposing restrictions on you, and limiting choices. Simply it is. The question is: Do you want your software used or just to die because your stance is to screw compatibility.

I agree with the writer of the article, and not the debian maintainer. And to think I took part in a discussion just like this starting from a thread on the Utah-glx mailing list with a nice guy from Loki. (You know they know what they are doing, cause making a good product is good business, making a hard to install and configure one is just plain stupid).

In ending if I were to grade two distributions of linux, say Debian and Mandrake, I'd give Debian a 1 and Mandrake a 6. It took me longer to figure out how to make and make a distribution debian that I liked (from windows) than it took to download the whole mandrake .iso cd. I've grown in my age, I'm tired of screwing around with things for hours just so I can use it.

Catch phrase: 'If I can't immediatly use it, screw it'

[reply] [top]

[»] Another approach
by dbt - Feb 15th 2000 20:00:50

Check out encap. http://www.encap.org/. It's
something much better to standardize on than
"dump everything in /usr/bin".

[reply] [top]

[»] .tgz forever
by joe schmoe - Feb 15th 2000 19:10:49

RPMs are evil. .debs are nice but it's not popular enough. .tgz packages forever. hehe :D emufreak (Mark Laws) - www.kontek.net/pp - www.vintagegaming.com

[reply] [top]

[»] Would it make just another package format?
by Corbeau - Feb 15th 2000 18:25:34

If we follow the idea of autoconf like management, here a preview list of what a system should provide¹:

• Which Files Hierarchies standard.
• daemons and start-up script supports.
• menu entries registration.
• Mime-type registration.
• Modules (for Kernel, Interpreters, etc.) registration.
• Suid registration.
• Documentation registration.
• Libraries installation.
• Alternatives registration (like multiple xdm, wm, pager, editor, etc.)
• (De-)Installation/configuration procedures.
• Other policies (strip/compression/etc.).

They're much more many things on some system and other systems also doesn't have half of them. Moreover, those things can be very different if you packaging for a single user (without root access), an official release, or for an intranet deployment.

For me, the Universal Source Packaging is acheived through .tar.gz using autoconf or imake or whatever other well distributed configuration system. Most sources using those systems are very simple to package and most distribution have their automated tools to created it at least a good skeleton for creating the basis of such package (at least, Debian has). With new standards like the .desktop file, you can add a lot on those tools even if you don't have a Gnome or KDE desktop. Just extract the information you need and voila!

I think however that including those informations into the package source is just a supplementary burden for the developpers, especially with all the platforms they already needs to support (not only Linux but Sun, HP-UX, AIX, Irix and even MS-W63K! ;). Except if you have a contributor who follow the target distribution closely, you got some chance to finally get a lesser quality package then you should.

So, MHO about all of this is:

Yes, this is a good idea but please! Let's the distros does must of the stuff with their own tools and be the more abstract possible (think object interface).

1: Take note That I'm a Debian Maintainer. So this is really a "partial" list of what a Debian Maintainer needs to decide when building a package.

[reply] [top]

[»] a note about the usefulness of autoconf
by astral - Feb 15th 2000 18:25:18

autoconf is an awesome program, and has made life incredibly
convenient for the sysadmins to the world. but some of our more
important things for the free software world simply use 'make'.
XFree86 is a large example, so are some other programs which have
beautifully written makefiles and such. autoconf and its cousin
automake are good, but aren't necessarily do-all tools. maybe an
'autoinstall' which passes options through to configure, builds, and
then does a simple 'make install' could be written for clarity, or whichever, but it would probably just be another little set of m4
scripts. source 'packaging' is kinda silly, but one command over
four can always help things.

laters,
astral ravenos

[reply] [top]

[»] Universal Package Management
by Gary Demofsky - Feb 15th 2000 01:21:24

Just to follow up on Bob Smith's idea of using XML package description formats. It may make a lot of sense to put distribution specific issues such as prefixes into a separate file, one per distribution. That way you don't have the same information repeated in a thousand (optimistically speaking) packages. You can extend this idea to work with windowing/GUI environments as well. You could set up descriptor files for Gnome and KDE where they would indicate what it would take to update menus, etc. appropriately.

In fact, this may be a good starting point in the design of the UPM where you can clearly define all the targets and the unique charateristics of each that need to be accounted for in a successful project.

This looks like an interesting project.

[reply] [top]

[»] Standardized installation
by Sean Russell - Feb 14th 2000 16:34:00

This whole issue would be greatly simplified if Linux understood the NeXTStep *.app format. For those of you who aren't familiar with the .app system, it was basically a directory structure standard; your standard .app was something like

	MyApp.app/
		bin/
			MyApp
		docs/
		lib/
		MyApp.icon

There are some problems with this; it doesn't address issues like shared library software, you still need a package management system to notify the OS of a new app and to check on dependancies, and it is really GUI app oriented. Still, it kept certain directories from getting overstuffed (/usr/bin, /usr/local/bin), and kept applications cohesive with their files. It is really too bad Unix didn't adopt this standard for its own apps.

--

[reply] [top]

[»] User interface integration already exists in Debian.
by mwr - Feb 14th 2000 14:20:55

What I would like to see is a software installation process which correctly integrates the installed application with whatever desktop or user interface I happen to be running - so, for example, if I'm running KDE, it puts the application in the appropriate place in the applications menu, installs any needed configuration files, MIME types, icons, help files, etc.

Already done in Debian packaging guidelines: /usr/sbin/update-alternatives, /usr/sbin/update-mime, /usr/sbin/update-inetd, /usr/sbin/update-passwd, /usr/sbin/update-ispell-dictionary, /usr/sbin/update-rc.d

[reply] [top]

[»] Even the Universal Package Manager only solves part of the problem.
by Talin - Feb 14th 2000 12:26:41

What I would like to see is a software installation process which correctly integrates the installed application with whatever desktop or user interface I happen to be running - so, for example, if I'm running KDE, it puts the application in the appropriate place in the applications menu, installs any needed configuration files, MIME types, icons, help files, etc. Same thing if I'm running GNOME, CDE, GNUStep, or whatever. The fact is, that simply "building" the package isn't enough to make it usable to the novice user. And in many cases, even "installing" (in the sense of what RPM does) falls short of the mark.

[reply] [top]

[»] Unification, Generalisation, etc.
by John Allsup - Feb 14th 2000 08:54:46

First off, I have read a number of comments saying

The FHS says where everything goes... stick with it.

If the files are stored on multiple hosts/partitions, how does one assemble the /usr heirarchy from this (note that I do NOT mean that /usr is on partition, /usr/local is another -- /usr/bin exists on multiple hosts, and needs to be merged according to user authentication, for an example). It is a contrived example, but should indicate how the FHS constrains one to the one box, one user, one system layout that most PC users are used to.

The FHS assumes that the binary and library names are unique for any given package, and that two different packages will not share a single file by name, except in the case that the files are identical. This is patently not the case where you, for example, want to have two versions running concurrently.

In short, relocatability should be enforced by any universal packaging solution, since the designer of the packaging system knows essentially nothing about the file layout on the target system. Further, the packaging system should be integrated with the build system, so that dependencies may be efficiently resolved. (Hopefully such a system will come from the Source carpentry contest -- one can dream)

[reply] [top]

[»] Yes, yes, yes
by Stootles - Feb 14th 2000 03:39:27

This is something that I have often thought over the last 2 years. RPM's and deb's....very nice. Makes life easy, they showed us it can be done.

I think now would be a very good time for a 'standard' to be created. Forget about writing the software for the time being. A good solid standard will do more for a single package solution than any software.

While I am not a coder, if I ever have the chance of assisting a supported standard in this area. I'll help, I'm there, the plane is booked.

A "supported standard", simple, a standard will only work if it is supported. As the linux world is standing on it's own two feet the only way such a standard will work is if the various distro's around, not only paticipate, but make moves to support the standard, regardless of result.

The GNU era has been largely responsible for Linux on a whole, surely we can agree on standard way to distribute and install apps.

[reply] [top]

[»] Great idea, but more than a few obstacles
by Cardinal - Feb 13th 2000 02:29:03

I would love to see this work on some level, even if it wasn't endorsed with open arms by all the major distros (This is extremely unlikely, anyway) But my own desires aren't enough to make this project the "right" thing to do, there needs to be a lot of support.

At the core, source packages are just tarballs with modifications and description files anyway. One would think making that source package universal wouldn't be a big jump, but it's certainly not a small one. RPM and Debian packages are built in very different ways, for example. Satisfying the requirements of both systems with one solution means it will be a very complex system.

At the distro level, different ones arrange packages in different manners. I'm not talking about just where individual files go, but what files go in which package. Returning to the Debian example, packages are organized in a drastically different manner from that of RedHat. For example, Debian packages Netscape into at least half a dozen different packages, tailored to whether the user wants dynamic or statically linked, what version, and so on. SImilarly, Debian breaks Gnome down into many more packages than normal. This allows a person to have only the pieces they want, and nothing more. (I prefer it this way, I know others don't)

Is this a direct obstacle? Not necessarily, because source packages can be configured to build any arrangement of binary packages. But again, this introduces complexities. And when I refer to compexities here and in the second paragraph, those should be read as "Long, arduous bureaucratic debate." Before anything can be implemented, a lot of debate and formality will have to be undergone.

Is the goal worth it? Only if a realistic expectation of adoption from the community is reached. In other words, is there sufficent support and interest. Ask the application developers. Ask the distro maintainers and managers. Ask the end users who build from source. See what they all think, and determine if it's something the people want.

[reply] [top]

[»] Universal Package Management
by Bob Smith - Feb 13th 2000 00:49:40

Well, getting everyone to agree on a universal package manager would be like makeing everyone use the same distribution. It would be nice, but its not going to happen. So, the problem becomes, how can we make it so that we only have to create one package file that will build packages for any distrib.

Posible solution:
Create an xml based package description format. Similar to how a rpm spec file works.
Every package manager works almost the same. They all describe what the name of the package is, version number, files to install, etc.
Then, there could be a xml->native converter that parses the xml file, and generates an rpm spec file(or whatever that dist or os uses) to produce a working package for that type of system.

I know what your thinking. Each platform has slightly different properties so this wont work. Already thaught of that. In the config file for upm, there can be system spacific variables defined. For example, prefix. Redhat uses /usr. Others use /usr/local.

In the xml file, you can also override any of the tags in it, with system spacific tags as well. For example, something like this:

<default>
<prefix>/usr/local</prefix>
</default>
<redhat>
<prefix>/usr</prefix>
</redhat>

Also, these variables could be over ridden by the command line.

So, heres how it would work. You find a program that you want. Say, gftp.
There is no solaris pacage for it, so you download the tarball (or upn could pull it down itself).
your run something like:

upm -b gftp-whateverver.tar.gz

and it will extract it where it needs to be acording to the way your system works, extract gftp.upn (the xml file) and generates the apropriate package description file for that system, and then builds a package for it.

Also, we could get something like apt going. but make it 2 way. not only could it pull down a package, if you build a package in the way described above, it could upload the generated package back up to a contrib server so that someone else wont have to build it.

The last problem I see is that most programmers dont like to deal with updateing spec files. The result is that the source will compile and install, but everyone who wants a package needs to edit the spec themselves and rebuild. Rather ugly. To solve this problem, an extention to automake could be devised. Since automake knows where a file will be installed, the Makefile.am's could be used to generate package file content lists for the rpm or other package. That way, the programmer wont have to maintain the list. It will be automatic if they are useing automake.

This is just an idea, and probably has a few design issues to work out, but it seems like a sound idea. Just will take a bit of work to implament. (dont look at me. I already have too many projects to work on. :) If someone wants to develop this idea, contact me and I'll try to help as I can.

Later,
Bob

[reply] [top]

[»] Re: Universal Source Package
by AuthLogiXXX - Feb 12th 2000 14:23:29

I believe that a uniform standard is indeed NEEDED, in order to advance the popularity and integration of multiple platform distributions. As a Linux user, with a prevailing taste for Slackware, (mostly for the good feeling you get when doing everything manually), I still prefer compiling everything from source, rather than using tgz packages, or, eghast RPMs. However, if a Universal Source Package is to be received widely, it will be NECESSARY to incorporate absolute fine tuning with respect to any and all variablesoptions in the MAKEFILE, etc. I believe this will keep the freedom of system control while allowing those who wish to automate their installations do so. Just a few thoughts I had on the subject. Very interesting idea. I hope to see it developed.

[reply] [top]

[»] what about following the fsstnd...
by Mike - Feb 12th 2000 14:13:21

or the fhs as it is called now. It describes how everything should be laid out. It is primarily aimed at Linux, but is supposed to be ably to be used by any Unix, or Unix-like OS. I think that at least getting all (or at least most) of the Linux distros to follow this would be a great help. I do realize that you are talking about a Unix-wide source package, and obviously we could never hope that all makers of Unix could switch over to using the FHS, I would just like to see Linux standarize on one (again I am dreaming) Assuming the USP becomes a reality, the FHS wouldn't really matter then...at least for installing packages. But for day-to-day system administration it would be very nice to have all systems laid out the same.

[reply] [top]

[»] e.g. url2pkg
by hubertf - Feb 12th 2000 13:48:08

The "url2pkg" script in the NetBSD Packages Collection
may be interresting to look at. It takes a simple URL of
a source .tar.gz (or whatever) file, downloads it, unpacks,
looks for commonly known configure methods (Imakefile,
configure-script, ...), and then emits a "Makefile"
suitable to start building a package.

Of course adding additional configuration parameters like for --configure scripts, ensuring that required packages are being pulled in etc. need to be made by hand today, but
it would really help pkg-creators if they would know what
other packages autoconf etc. look for and handle properly.
E.g. some pkgs install .el files if emacs is found, but will
run fine without it.

For a first step, it may be good only to know these tools
can/do interact with emacs. It will be a lot more difficult, though, to make this optional even for binary packages (RPM, ...).

Other user-configurable settings like whether or not to compress manpages may make things ore interresting too.

The mentioned API for crontabs, startup scripts etc. would
be another good thing to have in that Universal Source Package.


- Hubert

[reply] [top]

[»] Question
by Zarlox - Feb 12th 2000 09:21:14

So what is proposed here is first defining the standard and then make tools that convert the universal source package data into an rpm .spec file for example?

[reply] [top]

[»] I think it is a good idea
by moeffju - Feb 12th 2000 07:46:40

At least I would appreciate it. I remember too well the problems with just SuSE and RedHat rpms of one and the same program and the same platform. A standardized packaging method would help very much, I believe. Anyway I think it should not be added to autoconf, but instead be a separate program, like, but not being autoconf.

[reply] [top]