On 02/06/12 03:41, Chris Rees wrote:
On 5 February 2012 17:37, Olli Hauer<oha...@freebsd.org> wrote:
On 2012-02-05 18:23, Chris Rees wrote:
On 5 February 2012 17:21, Olli Hauer<oha...@freebsd.org> wrote:
On 2012-02-05 17:19, RyōTa SimaMoto wrote:
Hi, I'm a port maintainer for multimedia/qmmp, and some ports.
Before upgrading QMMP port, may I ask what is the common policy how to
offer Makefile OPTIONS containing a certain contradictory pair?
Actually the latest version of QMMP supports several versions of ffmpeg,
including 0.7.11, 0.9, 0.9.1, and 2012.01.22 that I tested to verify, so it
allows user to choose one of multimedia/ffmpeg or multimedia/ffmpeg-devel.
As you know you should not select both of them, otherwise they may conflict
with each other. I plan to provide an entry for each of them.
| ....
| [*] FFMPEG Support to playback by FFMPEG
| [ ] FFMPEG_DEVEL Support to playback by FFMPEG-devel
| ....
Then how should the Makefile proceed after the user's choice?
When the user did not install any of them yet, it's easy: The installation
would obey the user's order except when occationally both of them are
enabled that results to fail with an alert message. On the other hand, if
one of them are already installed, Makefile would know which one is
installed using 'exists(${LOCALBASE}/include/libavcodec/vda.h)' command.
So, in fact, there is no question that which version the user want to use.
The smartest way would be that provides a single entry which corresponds
to the existing version and hides the other entry that should not be
choosen. Unfortunately, the value LOCALBASE is not defined until
<bsd.port.options.mk> macro is loaded, that means we don't have any proper
steps to determine what version is already installed when the Makefile
construct the OPTIONS set. So we have no other way than to let the option
dialog always show both entries including quite wrong option.
Then if the user selects the other one that might conflict with the
installed version, there are six possible courses I assume.
0x000. Quit the session with alert message instructing user to retry
'make config' to choose the already installed one that Makefile
knows.
0x001. Dare to go through and expect that the depending port deals with
the conflicting issue.
0x002. Use the installed version and omit the choice implicitly.
0x004. Warn with short pause, then use the installed version and omit
the choice.
0x010. Store options into /var/db/ports/* as are that the user selects.
0x020. Store options into /var/db/ports/* with correction as actually
working. (If option variables are allowed to be changed at
testing stage.)
Is there any recommended policy? If so, what way or a set of ways should I
choose?
The following patch will do what you want, just polish the IGNORE messages.
Hopefully the include files do not change with the next versions.
--- Makefile.orig 2012-02-05 17:53:58.000000000 +0100
+++ Makefile 2012-02-05 18:16:00.000000000 +0100
@@ -35,6 +35,7 @@
FLAC "Support to playback FLAC files" on \
MUSEPACK "Support to playback MPC files" on \
FFMPEG "Support to playback FFMPEG files" on \
+ FFMPEG_DEVEL "Support to playback FFMPEG-devel files" on \
Hm, breaks itself by default ;)
where?
(Maybe I had not enough sleep tomight)
Here (both are on by default):
+.if defined(WITH_FFMPEG)&& defined (WITH_FFMPEG_DEVEL)
+IGNORE= coose only one FFMPEG option
+.endif
I still think depending on ffmpeg binary and defaulting to
multimedia/ffmpeg and just having the one OPTION is the simplest
solution.
Sure, but the OP maybe wants to give the ability to choose which ffmpeg version
in case the ffmpeg port is not already installed.
I'm just pointing out that it's not easy, and probably not a good idea :)
If the user cares that much about which ffmpeg version is installed
s/he would have installed it already.
True +1.
Usually it is this that breaks most similar ports (xine, mplayer, etc).
Can't install devel without breaking, and to fix you have to install the
non devel version.
JIC: this is not an official complaint, or a stolen thread. Just an
observation for the OP to consider when setting their own port.
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
