Bug 101728 - [MAINTAINER] audio/cmus: update to 2.0.3
Summary: [MAINTAINER] audio/cmus: update to 2.0.3
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Adam Weinberger
Depends on:
Reported: 2006-08-09 21:50 UTC by Simon Olofsson
Modified: 2006-08-10 17:50 UTC (History)
1 user (show)

See Also:

cmus-2.0.3.patch (6.87 KB, patch)
2006-08-09 21:50 UTC, Simon Olofsson
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Olofsson 2006-08-09 21:50:15 UTC
- Update to 2.0.3

Generated with FreeBSD Port Tools 0.77
Comment 1 Adam Weinberger freebsd_committer 2006-08-09 23:11:06 UTC
Responsible Changed
From-To: freebsd-ports-bugs->adamw

I'll take this.
Comment 2 Adam Weinberger freebsd_committer 2006-08-10 14:56:25 UTC
State Changed
From-To: open->feedback

Set state to feedback for the following: 

As stated in a previous email to maintainer, I do not believe 
that OPTIONS are appropriate here. They prevent the system 
from registering de facto dependencies, and will lead to 
inevitable broken library links. 

Also, please double-check about removing the bash dependency. 
cmus was never before able to build without bash; have you 
tested it on a bash-less system?
Comment 3 Simon Olofsson 2006-08-10 15:43:21 UTC
The Build system was converted from bash to sh on 2005-11-13, see:
Building cmus without installed bash worked fine for me.

I understand your reasons for not using OPTIONS. But I don't think we
have to worry about broken dependencies here. When you disable
libmodplug in the OPTIONS, the configure script for cmus will be
invoked with CONFIG_MODPLUG=n. Regardless if it finds libmodplug or
not, it will not build against it, because it has been explicitly
disabled. If one would do a configure without CONFIG_MODPLUG=n, then
the value would be set to a and cmus would build against it, if it
finds the libraries installed.
So if you enable an OPTION cmus will be told to build against it and
it will be a registered dependency and if you disable it, cmus will
not build against nor depend on it.
So if this is the only objection against OPTIONS it is solved as far
as I can tell.

On Wed, Aug 09, 2006 at 06:14:36PM -0400, Adam Weinberger wrote:
> The reason that I had stayed away from using OPTIONS is that it cannot 
> make intelligent decisions based upon what's already in the system.
> For example, say that you have libmodplug installed. You don't change 
> any of the default OPTIONS, but during the build, cmus finds libmodplug 
> installed. It will therefore build against it, but there won't be a 
> dependency registered against it.
> Then, in the future, say you deinstall libmodplug. The ports system 
> won't give any sort of error, but suddenly cmus will stop working, 
> complaining that it's missing a required library.
> OPTIONS is good for setting build options, not for choosing what modules 
> to support. You're the maintainer now, but I strongly suggest that you 
> resubmit the PR without the OPTIONS changes.

Mit freundlichem Gruß,
With best regards,

Simon Olofsson
Comment 4 Simon Olofsson 2006-08-10 17:06:58 UTC
I'm sorry, but I made a little mistake. The Options which are default
on should be tested with WITHOUT_*.
Here is a new patch which incorporates this:

Mit freundlichem Gruß,
With best regards,

Simon Olofsson
Comment 5 Adam Weinberger 2006-08-10 17:40:38 UTC
I'd missed what the CONFIG_FOO={y,n} stuff did. Looks like you've 
thought of and solved all the issues I had, and I'm glad that they 
finally removed the bash necessity! Sorry about the delay; I'll go ahead 
and commit this.

# Adam
Comment 6 Adam Weinberger freebsd_committer 2006-08-10 17:46:02 UTC
State Changed
From-To: feedback->closed

I've committed this with the olofsson.de patch. 

Though, FTR, I was under the impression that the OPTIONS system 
automatically set both WITH_FOO=yes and WITHOUT_FOO=no 
automatically for each option.