Re: gnu packaging ideas

[pancake]

> I think "lisp-like" syntax should be avoided. Remember that this is all just
> a method for developers to package their softare, or for software to be
> packaged for them. You need to remember that lisp syntax is inredibly
> foreign to the  majority of devlopers - why force them to learn a whole new
> thing just to package software?

sexp syntax is nice. Easy to read and powerful. So i think you won't learn it.
BTW we can use simple double-dot separated values like Java property files or
Debian database.

I couldn't understand why learn a new useful structured syntax could be bad.
SEXPs structures could be compared to XML.

> - package name (the same as the file) f.ex "gcc.gnu-package"
> >- package version
> 
> I think you probably meant this, but I think we also need to inlude the
> softwares version. Most package managers use the softwares version, then
> have a package revision number relating to  how many times that particular
> version has been packaged.

The pkg version is important because you'll be able to manage diferent versions
of the same package. And upgrades/updates would be more secure, because you'll
always be able to switch to the old version inmediatly because they'r just 
"views".

> - dependencies and version ranges supported for dependencies
> 
> I think that complex dependency relationships are a must. That is, I don't
> think this should be a simple: "requires blah >= 2.0" more "requires blah >=
> 2.0 not 2.6 not 2.7", etc.

Yes, it's complex, but is powerful.

> - binary repositories path
> >- one line description
> >- long description
> >- sha1/md5 hash of the binary file
> >- name/mail of the maintainer
> >- ...
> >- something more?
> >
> >It would be good to allow to choose some "flags", but to fix the
> >complexity
> >of this we could pack different packages with suffixes like this:
> >
> >classpath.gnu-package
> >classpath-x11.gnu-package
> 
> This is silly and impractical, and leads to a large number of
> hard-to-maintain and almost reduandant meta files and packages. There are
> many packages that offer a lot of customization - how'd you like to be the
> maintainer that has to maintain 20 different versions of your application?
> Think of something like PHP - that can  have everything from 0 to around 100
> dependencies, depending on your features.
>
> The best way, using this model, is to try to build core packages that are a
> modular as possible, then offer extension packages. A good example of this
> is "gcc-core', "gcc-objc", "gcc-c++", etc.

That was what I'm trying to say, probably i've not exposed my ideas as clear as 
I think.
So I mean that classpath-x11 depends on classpath, so classpath-x11 just gives 
you
X11 support to the classpath.

> The west way in general of doing this is to use flags and source packages.

But then you've no way to get these packages in binary form. So people using
binary packages will not be able to enjoy this flags.

> So, this package descriptors can be stored on a directory updateable with
> >gnuarch/rsync/git.., so we could get different sources on the same repo.
> >
> >stut will browse this database and resolve the dependency tree. The binary
> >tarballs would be fetched from the repostories referenced by the package
> >descriptor. so we could define some base repositories like FTP's, etc.
> >
> >stut will fetch the .gnu-package file (a tarball), and configure't.
> >
> >So, it would be nice to pack some scheme scripts inside the package:
> >
> >[tarball]
> >packagename-version/...
> >metadata/...
> 
> Why? We already have the .gnu-package file full of metadata, which told us
> where to fetch the package from. I can understand having install scripts in
> the package, but thats it. Maybe just a copy of the .gnu-package file for
> single distribution?

If we don't dup this info we'll not able to install a binary package that is
not registered in the database. (like dpkg -i blabal), So metadata must be 
there.
metadata must be about <1KB, so I think it's no problem.

> What are the point of the "scheme scripts" you mention? I can't see any
> advantage to using scheme as a syntax in packages - like I said, thats
> forcing typical package developers to learn an extremely foreign language
> just to package their software. Most package managers use their own format
> for files/scripts relating to the package manager, then use shell scripts
> for pre/post install scripts

Ok ok, don't cry. I'll no force anybody to learn LISP anytime. BTW you can
write SEXPs without knowing lisp or scheme, right? That's the idea. The 
lisp-like
syntax could be something like that:

(gnu-package
        (name "foo")
        (version "1.2")
        (description "This is the latest foo package")
        (dependencies ( (>= "bar" "1.2")
                        (>= "bla" "0.3")))
        (post-install (system "echo hello world")))

That just a dumb proposal, but i think it's cleaner, extensible and powerful.
So if you want to write a shellscript you can do't. But IMHO it's better to
keep the sexp form to ease the parsing.

> Has anyone considered also offerin a source-based solution, like the popular
> Ports system in BSD distributions, or in Gentoo GNU/Linux's emerge program?

I've been using pkgsrc on Bee GNU/HURD. BTW the GNU/GSC is what we must use on 
the GNU.

--pancake