>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>On Sunday, January 20, 2002, at 01:43  PM, Martin Costabel wrote:
>
>>Gordon Messmer wrote:
>>>
>>>On Fri, 2002-01-18 at 03:38, Max Horn wrote:
>>
>>>>* Move to a new package format - yes or no, and which. This has to be
>>>>carefully designed, I think.
>>
>>I vote NO. There are excellent reasons for staying with the present
>>format. IMHO one of the secrets of Fink's spectacular success is just
>>this extreme simplicity of the format of the info files. If you
>>complicate this, like with XML where you need special tools for editing,
>>or with rpm which is much more complex, you will loose many of the
>>package contributors. I don't mean you shouldn't add (carefully
>>selected) additional features, but please keep the simple human readable
>>and writable text format.
>
>Quite frankly, the current format isn't flexible enough. Some sort 
>of modules/variants support is really needed, if only because all of 
>the -nox and -osx and -whatever packages are going to start 
>cluttering the list of packages, which will make it harder to find 
>the package you want, etc.
>
>Another reason for modules/variants support: I am in the middle of 
>building GRASS for the umpteenth time so that I can get as many of 
>its modules into the GRASS package as possible. (On my computer, at 
>least, the GRASS package in CVS doesn't actually build the 
>PostgreSQL or ODBC modules.
>) It takes  two or more hours to build GRASS (with nice -n -20, at 
>that) with all of its modules. Let's say someone doesn't want/need 
>PostgreSQL support in GRASS. Should I create a grass-pgsql package? 
>What about grass-atlas, grass-odbc, grass-tcltk, grass-gl, etc? With 
>modules, I could create a GRASS package and bundle a bunch of 
>optional modules into it.

While I see your point (and agree with it), remember that before you 
add a package for submission or commit it, you'll have to test each 
of the different variants, to ensure that there aren't any apparent 
problems with the package and its modules/variants. (Having the 
support just makes it easier for the user, and as you said, reduces 
the clutter.)

>
>I have to admit, simplicity is compelling. I really like how easy it 
>is to write an .info file. However, I think that XML can be almost 
>as simple, especially if the file format works with 
>/Developer/Applications/PropertyListEditor.app.
>
>Just my 2 cents.
>
>Daniel
>


_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to