On 18/02/2006, at 11:59, Adam wrote:

>>> Module Name:	pkgsrc
>>> Committed By:	adam
>>> Date:		Fri Feb 17 23:49:19 UTC 2006
>>>
>>> Modified Files:
>>> 	pkgsrc/misc: Makefile
>>> Removed Files:
>>> 	pkgsrc/misc/celestia-gnome: DESCR Makefile PLIST
>>> 	pkgsrc/misc/celestia-gtk: DESCR Makefile PLIST
>>> 	pkgsrc/misc/celestia-kde: DESCR Makefile PLIST
>>>
>>> Log Message:
>>> Removed celestia{-gtk,-gnome,-kde}; use celestia/options.mk to  
>>> select a gui
>>
>> Why?  Now binary package users are stuck to whichever UI is the  
>> default.
>
> It's easier to maintain this way.

I haven't looked at that package myself... but, really?  If you have
multiple options, you should build the package with each of them during
an update to verify they still work.  Doing this with different packages
is easy, not so much with options.  Also, bulk builds will not catch
build problems with the different GUIs...

> Why not making binary packages for different options? :)

Yes, why not?  I'm not a big fan of build time options.  For me, the
less, the better: a binary-only user should be able to have a wide
variety of applications and not be forced to rebuild them himself.
This is why many of my packages do not have any option and, whenever
possible, they are provided in the form of different packages.  Again,
I haven't looked at celestia, but if it was difficult to maintain, I
guess it'd have been simplified a bit to keep the different packages.

I would like us to enforce a policy so that pkgsrc was binary-package
friendly; and this means lessening the number of available options.
In my opinion, it's a good selling point over, e.g., the ports and
portage.  In fact... this is one of the reasons I liked pkgsrc when I
saw it: the ports were a real mess with all those options.
Unfortunately, it seems we are getting there...

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
The Julipedia - http://julipedia.blogspot.com/