Re: gnu packaging ideas

[Alfred M. Szmidt]

   Sorry (again) for the lag O:)

I prefer very late than never. :-)

   > Sounds good, though the format of each sexp (specially the
   > dependency stuff) needs to be pondered about.  I think that much
   > of this data can be grabbed from the Free Software Directory.

   Yup, having an easy to grab all this info will make a database easy
   to be generated. We must discuss about the format itself. SEXPs,
   Double dot separated values, etc.. any proposal? idea?

I prefer sexp's since it allows us to do crazy things, if we want to.
Double dot seperate values, etc don't.

   > I think this should be an optional feature, compiling the same
   > package with different flags is alot of work.  I'd prefer that
   > "our" packages are always compiled with all the features that are
   > provided.  This will reduce our workload considerably, if then
   > someone wishes to have an Emacs without X, they can create a new
   > package called emacs--nox--21.4.tgz or similar.  What do you
   > think?

   I think that there'r some features that must force the package to
   be splitted in two. Like the X support that carries a lot of
   dependencies.

We can provide such a feature, but I don't think _we_ (as in those who
package GNU) should split packages into X vs. non-X.  Recall, this is
a full system, so we should have sane defaults.  If then someone else
wishes to change these defaults, they can always create a package that
they distribute.  I like the way the OpenBSD people do this, basically
it is `we only support the defaults, if you change them, you are on
you're own'.  This will result in less headaches for us when trying to
help people, if they say that they use GNU 1.0, then we know _exactly_
what they have installed, and we can reproduce it on our own systems
easily without having to download lots of strange programs.

   >    In metadata we could store install/deinstall scripts.
   > 
   > A package must work without these.  Simply extracting the package
   > to /stow should be enough.

   I think having pre/post install scripts would be pretty nice.

We all agreed that they should be avoided at all costs.  There are
several issues with them, for one, what happens if you have a pre/post
install/deinstall script that _must_ be ran for the package to be
successfully installed?  Then a simple `tar -C /stow -xzvf
package.tgz' won't work, which is how the package manager works.  If
we, in the future, come to a point where we really really need
pre/post install/deinstall scripts, then we can add such a thing.  But
I have looked and I cannot see any reason why any package really needs
it, one can work around what is done in the pre/post install/deinstall
script by other means.


Cheers!