Current OP News

Milestone 2 Released

Submitted By : Will Andrews
Milestone 2 has been rolled and released! Check out the URL and download op-0.2.tar.gz and optionally verify the integrity. To try out OpenPackages Milestone 2 (Release 0.2), untar the tarball then in op/tools run the “sandboxtest” script. Report any success or problems to the mailing list. A huge amount of work went into this release in the last month. I’m proud of the group that got together and finally put together something a large number of people can use. Check out the SUPPORT listing at ftp://ftp.openpackages.org/op/SUPPORT to see what works. AIX should work, but doesn’t currently due to some issues. It’s being worked on at the moment.

Milestone 2 Date Set

Submitted By : Will Andrews
Milestone 2 is right around the corner. The developers have agreed to the release date of July 31, in which OpenPackages will be able to bootstrap and compile a sample package in a sandbox on various UNIX platforms, including FreeBSD 2.x/3.x/4.x/5.x, OpenBSD, NetBSD, HP/UX, Solaris, AIX, and possibly Linux, OSF1, and IRIX, on platforms ranging from i386 to hppa to powerpc to ia64 to sparc64. Stay tuned…

Progress on Milestone #2
Submitted By : Chris Coleman

We have been making progress on Milestone #2. I just committed a patch that allows Mac OS X to compile the existing pkg_tools.

Right now the sysem works on NetBSD and FreeBSD. I have a to figure out an elegant way to patch two small bugs and it will be working for Mac OS X. Harlan is working on porting the system to HPUX as well as getting the whole tools directory to bootstrap more cleanly.

Will Andrews is working on porting Fake and Flavors from OpenBSD. If anyone else wishes to pitch in, drop me a line.

Click the link to read the commit message.

Package Directory Layout
Submitted By : Chris Coleman
Harlan began a thread trying to figure out how the directory structure will become and many peolple have chimed in on how it should look.

There appear to be two schools of thought. Organize it Alphabetically, or Catagorically. Some are even suggesting how we could do both.

Click the link to follow the e-mail thread.

OP Project Goals

Submitted By : Chris Coleman
Will Andrews asked the question: “What do we want out of this project?” and gave a few answers:

Things Will would like to see happen:

  1. make(1) and pkg_*(1) tools centralized to one repository shared by the representative BSD’s, and made as portable as possible to allow other operating systems to use OP without too much hassle (read: easy bootstrapping).
  2. pkg_*(1) tools redesigned somewhat for additional flexibility as I described in a previous email. Things that really need to be added or improved on in the packaging system: library-ifying, network-wide databases for easy network management, extended configurability to make life easier both for developers and users, a fluid mechanism for signing and verifying packages, clean mechanisms for handling relationships between packages, clean upgrade mechanisms, and so on.
  3. Unified pkgsrc system: all pkgs in one centralized repository. This will allow for security audits to become effective across all OP-supported operating systems. Modify makefile core to make the packaging side of it as abstract as possible to allow other packaging systems to use the result of pkg builds, to improve vastly on portability.

Click the Link to follow the e-mail thread.

Mac OS X Fink
Submitted By : jcs
Fink seems to be a similar effort on Mac OS X to Open Packages. Maybe something the OP effort should be involved with?

Reaching Milestone 2
Submitted By : Chris Coleman
To reach Milestone #2, we need to test the existing package tools and make sure they build on FreeBSD, NetBSD, OpenBSD, Darwin, and BSD/OS. People are welcome to test them on other platforms and send patches.

I have made a tarball of the current sources available so people can test this on various systems.

I just tried this on FreeBSD 4.2 so I know that works. Please let me know how the rest of the systems go so I can cross them off my list.

Fetch VS Wget
Submitted By : Brook Schofield
With the unanimous chorus of “anything is better than FTP” a debate has raged that fetch used primarily for FreeBSD’s Ports collection should be used as the file transfer subsystem for OpenPackages. Due to the portability problems of fetch there was a suggestion to use wget (which is more portable than the fetch code but GPL licensed). curl which is regarded as portable code could be a replacement to fetch since it is both BSD-licensed and provides a library libcurl.

Any thoughs?.

Milestone #1
Submitted By : Chris Coleman
I just imported the zsh package into the tree and it builds using the latest op-make and package tools. This means that there is actually something in the CVS tree that you can download and try out.

Now we are focusing our attention on porting this minimal package set to all our target OSes. I expect rapid progress on this phase of the project. Feel free to port this to your favorite OS and submit patches.

If you haven’t checked out what’s in CVS, now is the time to do it. Please test out what is there and post comments so we know what is working. If it needs fixing, send a patch instead.

How do we handle differences in make(1) on different OSes?
Submitted By : Chris Coleman
Hubert Feyrer has pointed out that the ODE make modifiers currently in NetBSD’s make conflict with the make modifiers that would be important to OpenPackages – particularly :L and :U. Marc Espie suggested adding a feature to make(1) to allow it to use different interpretations with a switch.

Core Compression Format
Submitted By : Chris Coleman
The File Compression format for OP has been in discussion. It has been asked whether or not to use ZIP as the native format for OP. So far the discussion seems to favor .TGZ and BZIP2 ala .TBZ for use as the natively supported formats.

OP CVS Directory Layout
Submitted By : Chris Coleman

The CVS repository has been setup and the repository is at cvs.openpackages.o rg/cvs. The only directory currently in existence is ‘www’.

We need to decide on the layout for the rest of the project. Should the main project module be called ‘op’, ‘opkg’, or something else? Should there be a se parate module for tools that we expect to be integrated into the base OS of syst ems using OpenPackages to be used by projects that don’t have the package tools, ie some dists of Linux. (or will it be bundled in the OP source tree.)