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! _______________________________________________ gnu-system-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-system-discuss
