-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday, January 18, 2002, at 11:48 AM, Max Horn wrote: > 2) Allow "options" that can be combined at will: > * the base settings, no options > * "ssl" - will enable ssl support > * "nox" - will build without X11 > * "nognome" - will build wihtout I like 2. It would be nice if many of the options were standardized (as you seem to be suggesting) so that per-user defaults could be set up in a config file (e.g. /sw/etc/fink.conf) as someone else suggested. (I don't like the double negatives either.) > Now the next step. How does a user specify options? > Mabye like configure does: > fink install foo --with-gnome --with-japanese > Or like the current way: > fink install foo-gnome-japanese > Or maybe completly different > fink install foo (gnome, japanese) I like the first and the third way. The second way is confusing to me. Also, I like the idea of psuedo-options, e.g. foo --with-defaults, foo (mydefaults), foo (all). I'm going to stop saying "I think someone else suggested this too" because I can't keep track of it all in my head. Oh, and I like the interactive way of doing it too (easier for newbies?), but I wouldn't want to use it. My normal Fink usage is something like: sudo -v ; yes '' | sudo nice -n -20 fink install pkg pkg2 ... pkg14 > fink-install-pkg1-...-pkg14.txt 2>&1 & So interactive packages that with defaults I don't like sometimes give me trouble. Those and qt. I made a 700+ MB log file by trying to update qt that way... 700 MBs of "Do you want to accept the qt license [yes/no]?" (paraphrased)! > And how do we map all this to dpkg names? One way would be to take the > list of options, sort them alphabetically, and add concat them with the > package name using "-". > So the above examples would result in the .deb for foo-gnome-japanese-x11 Hmmm... what about path length limits? As much as I hate to say it, I think concatenating all the options together and making a hash would work the best. (Similar to having each option assigned a letter, but less fragile because the addition of a new option and the removal of and old one won't break anything... the name remains unique.) We would also have to teach dpkg to recognize them as different "versions" of the same package (i.e. they conflict with and replace each other). Actually modifying dpkg would probably be best. (Although I don't know enough about dpkg to say for sure.) > What do you guys think? Am I crazy? :) No, I've been asking for a subset of this for a while. It's good to see this discussion happening! It's also encouraging that 1.0 has actually been mentioned! Daniel - -- PGP public key: http://mwdesign.dyndns.org/~daniel/publickey.txt ACA4 FA04 4033 0569 C626 AA1A C489 25A5 5F67 C125 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (Darwin) Comment: For info see http://www.gnupg.org iD8DBQE8ST57xIklpV9nwSURAg9PAKCMwfqw7VbcTGKqXRfvRoS4DUdl2QCfTgnn yVRvp/VSVTPFqxfpyXbNt5I= =rjjn -----END PGP SIGNATURE----- _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
