Bug 193004 - -nox11 ports should depends on -nox11 ports
Summary: -nox11 ports should depends on -nox11 ports
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Baptiste Daroussin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-26 01:21 UTC by Koichiro Iwao
Modified: 2015-06-05 18:20 UTC (History)
3 users (show)

See Also:


Attachments
patch (391 bytes, patch)
2014-08-26 01:21 UTC, Koichiro Iwao
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Koichiro Iwao freebsd_committer 2014-08-26 01:21:47 UTC
Created attachment 146284 [details]
patch

% make -C /usr/ports/graphics/ImageMagick-nox11 all-depends-list | grep ghost
/usr/ports/print/ghostscript9

graphics/ImageMagick-nox11 now depends on print/ghostscript9 but this is not user friendly because when people want to install ImageMagick-nox11, they don't want to install X11 relevant ports.

According to Mk/bsd.port.mk around line 1954, ghostscript with -nox11 suffix will be installed if WITHOUT_X11 variable is defined.  I think WITHOUT_X11 should be defined when X11 option is disabled.
Comment 1 John Marino freebsd_committer 2014-08-26 07:06:13 UTC
will ghostcript 9 conflict with ghostscript-nox11?

Maybe it is this way to pick the most common of the two conflicting packages (if they conflict).

That said, if they are picking -nox11 packages, then likely they use -nox11 versions everywhere.

over to maintainer
Comment 2 John Marino freebsd_committer 2014-08-26 07:06:53 UTC
stupid bugzilla.
This time, over to maintainer.
Comment 3 Koichiro Iwao freebsd_committer 2014-08-26 08:14:17 UTC
Yes, ghostscript9 conflicts with ghostscript9-nox11. When I try to upgrade ImageMagick-nox11, portmaster installs ghostscript9 even though ghostscript9-nox11 is already installed.

% pkg version -Ivl\<
ImageMagick-nox11-6.8.9.4_1,1      <   needs updating (index has 6.8.9.4_2,1)

% pkg info |grep ghostscript
ghostscript9-nox11-9.06_7      Ghostscript 9.x PostScript interpreter

% sudo portmaster ImageMagick-nox11
(snip)
===>>> The following actions will be taken if you choose to proceed:
        Upgrade ImageMagick-nox11-6.8.9.4_1,1 to ImageMagick-nox11-6.8.9.4_2,1
        Install print/ghostscript9
(snip)
===>  Installing for ghostscript9-9.06_7
===>  Checking if ghostscript9 already installed
===>   Registering installation for ghostscript9-9.06_7 as automatic
pkg-static: ghostscript9-9.06_7 conflicts with ghostscript9-nox11-9.06_7 (installs files into the same place).  Problematic file: /usr/local/bin/dvipdf
Note: in order to use the script "dvipdf", dvips must be installed.
This program may be provided by either print/dvips or print/dvipsk-tetex
(print/dvipsk-tetex may be preferable since it doesn't conflict with
tetex things).

FAPIfontmap and FAPIcidfmap in /usr/local/share/ghostscript/9.06/Resource/Init
have to be configured if you want to use FAPI feature.

*** Error code 70
(snip)
Comment 4 Koop Mast freebsd_committer 2014-09-01 10:42:17 UTC
This is actualy a bug in bsd.port.mk. The logic that switches between the normal ghostscript port and -nox11 doesn't check OPTIONS for X11.

This is tricky to do because not all ports might set the X11 option.
Comment 5 Koichiro Iwao freebsd_committer 2014-09-02 00:10:43 UTC
When I install -nox11 suffix port, all depends ports if have -nox11
Comment 6 Koichiro Iwao freebsd_committer 2014-09-02 00:13:22 UTC
Mistake posting a comment.  Anyway, generalized the problem.
-nox11 ports should depends on -nox11 ports if depended ports have -nox11 option.
Comment 7 florian.heigl 2015-04-04 17:02:31 UTC
Could we have a non-general patch to fix just the imagemagick vs ghostscript situation.
It's understood that this is a more generic problem but as far as I can see, it breaks all those nice poudriere builds since since half a year?

pkg's default packages are useless for running on servers, since they're all desktop-x11-y.
self building doesn't work since ports are too broken.

What I'm trying to say:
This isn't a good starting situation to let it dangle and wait till we can come up with a nice and clean generic solution.
Comment 8 Andres Montalban 2015-06-05 18:20:58 UTC
Hey guys,

I'm also interested in a solution for this as I have the same issue as the original poster.

I think that importance should be changed because it affects all people that uses FreeBSD for servers (Which is probably most of the people that use FreeBSD).

Thanks!