More an autopackage

[Geoffrey Wossum]

Hi again,

I want to work on the unified front-end to native packaging systems like I
posted before, but the bossman doesn't want to wait until that's useable.
So the autopackage front-end is going to be YASP (yet another side
project) for me.

Anyway, here's some of my thoughts about it:
1) written in Python 

2) At first, it'll just be a unified front-end to rpm and dpkg and
friends.  Then, some of the more difficult issues that have been brought
up will be tackled, such as package dependencies and automagically
deciding the right files and locations for platforms.

3) I think the interface to it will be a file specifying the requirements
for the package.  Files to include, where to install them, pre and post
install scripts, etc.  At first, developers just write this file by hand.
Even this is a great improvement.  Then, automake gets modified to be able
to automatically create this spec file.  (Is this a good idea?)

4) Is autopackage a good name?

5) I'm really a software developer, not a packaging guy.  That's why this
seems like such a good idea.  I want to write code, not mess with
packaging systems.  But, I really don't know that much about packaging.
So I'll probably need some help with the packaging details.

6) When I get going with Actual Code (TM)  (within a couple of weeks),
I'll setup a project on sourceforge for this.

And finally, thanks to everyone who responded to my initial post.

---
Geoffrey Wossum
address@hidden