Re: dependency explosions
Thanks Miroslav, Cyrus is marked as automatic and I don't understand why that is. But I've removed it as I only needed its libraries for Dovecot and, as you pointed out, that isn't necessary any more. All working! Thanks for your reply, Graham On 06/10/2016 11:23, Miroslav Lachman wrote: > Graham Menhennitt wrote on 2016/10/06 01:49: >> Sorry, I just read that UPDATING entry again. Cyrus is only provided to >> Dovecot if Postfix is present. I do not have Postfix present. So, I >> think that I do need to install Cyrus explicitly. >> >> So, back to my original question, why does "pkg autoremove" want to >> uninstall Cyrus when I explicitly installed it from the port? > > pkg autoremove is working with pkg internal database. If you install > some ports directly with command "pkg install SomePort", then this > ports is nor marked as autoamtic. If some port is installed as > depedency, then it is marked as automatic and if parent port is > removed, then this automatic port can be deleted by "pkg autoremove" > > You can use "pkg query" to check what is marked as automatic > > pkg query '%a %n' | sort > > You can change this settings by "pkg set" (see man pkg-query example) > > EXAMPLES > Change a package from automatic to non-automatic, which will prevent > autoremove from removing it: >% pkg set -A 0 perl-5.14 > > > > Why you need cyrus-sasl? Do you use some tools from this package or > just some libs? > The Dovecot / Postfix case is that Dovecot have it's own internal SASL > libs and Postfix from some version have internal support for Dovecots > SASL and do not need to be build with Cyrus-SASL. But it is not > related to you if you are not using Postfix. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
On 05/10/2016 23:29, Graham Menhennitt wrote: > When I run it, it tells me that it's going to remove my cyrus-SASL port. > I installed that (via its port) so that I can use SSL/TLS authentication > on my Dovecot server (installed via the dovecot2 port). So Cyrus is not > a build dependency of anything - why is it offering to remove it? Dovecot has it's own SASL implementation. It doesn't need the equivalent Cyrus version. http://wiki.dovecot.org/Sasl 'pkg autoremove' is offering to remove cyrus-sasl because cyrus-sasl was presumably originally installed as a runtime dependency of some port (and hence marked as 'automatic'), but that port no longer depends on cyrus-sasl, so pkg sees cyrus-sasl as a candidate for removal. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: dependency explosions
Graham Menhennitt wrote on 2016/10/06 01:49: Sorry, I just read that UPDATING entry again. Cyrus is only provided to Dovecot if Postfix is present. I do not have Postfix present. So, I think that I do need to install Cyrus explicitly. So, back to my original question, why does "pkg autoremove" want to uninstall Cyrus when I explicitly installed it from the port? pkg autoremove is working with pkg internal database. If you install some ports directly with command "pkg install SomePort", then this ports is nor marked as autoamtic. If some port is installed as depedency, then it is marked as automatic and if parent port is removed, then this automatic port can be deleted by "pkg autoremove" You can use "pkg query" to check what is marked as automatic pkg query '%a %n' | sort You can change this settings by "pkg set" (see man pkg-query example) EXAMPLES Change a package from automatic to non-automatic, which will prevent autoremove from removing it: % pkg set -A 0 perl-5.14 Why you need cyrus-sasl? Do you use some tools from this package or just some libs? The Dovecot / Postfix case is that Dovecot have it's own internal SASL libs and Postfix from some version have internal support for Dovecots SASL and do not need to be build with Cyrus-SASL. But it is not related to you if you are not using Postfix. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
Sorry, I just read that UPDATING entry again. Cyrus is only provided to Dovecot if Postfix is present. I do not have Postfix present. So, I think that I do need to install Cyrus explicitly. So, back to my original question, why does "pkg autoremove" want to uninstall Cyrus when I explicitly installed it from the port? Thanks, Graham On 6/10/2016 10:12 AM, Graham Menhennitt wrote: Thanks for that, olli. I didn't understand how I'd missed the fact that Dovecot now included Cyrus. So I had a look at /usr/ports/UPDATING. Searching for Dovecot shows a mention of it in the entry at 20160228. However, that's entitled "AFFECTS: users of mail/postfix", and I don't use Postfix. I think that Dovecot should have its own entry in UPDATING for that change too. Graham On 6/10/2016 9:38 AM, olli hauer wrote: Postfix in combination with dovecot doesn't require cyrus, since some months dovecot support is always provided by postfix. But i"m sorry and cannot expliain why cyrus is installed on your system -- send with broken GMX mailer client, sorry for tofu and html scrap On 06/10/2016, 00:29 Graham Menhennitt wrote: On 6/10/2016 8:20 AM, Mathieu Arnold wrote: > Le 05/10/2016 à 22:04, Julian Elischer a écrit : >> Another thing that might be good woudl be a way to tell ports "remove >> all the ports that were just build dependencies". > pkg autoremove > Thanks for that Mathieu - I didn't know about that one. However... When I run it, it tells me that it's going to remove my cyrus-SASL port. I installed that (via its port) so that I can use SSL/TLS authentication on my Dovecot server (installed via the dovecot2 port). So Cyrus is not a build dependency of anything - why is it offering to remove it? Thanks, Graham ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
Thanks for that, olli. I didn't understand how I'd missed the fact that Dovecot now included Cyrus. So I had a look at /usr/ports/UPDATING. Searching for Dovecot shows a mention of it in the entry at 20160228. However, that's entitled "AFFECTS: users of mail/postfix", and I don't use Postfix. I think that Dovecot should have its own entry in UPDATING for that change too. Graham On 6/10/2016 9:38 AM, olli hauer wrote: Postfix in combination with dovecot doesn't require cyrus, since some months dovecot support is always provided by postfix. But i"m sorry and cannot expliain why cyrus is installed on your system -- send with broken GMX mailer client, sorry for tofu and html scrap On 06/10/2016, 00:29 Graham Menhennitt wrote: On 6/10/2016 8:20 AM, Mathieu Arnold wrote: > Le 05/10/2016 à 22:04, Julian Elischer a écrit : >> Another thing that might be good woudl be a way to tell ports "remove >> all the ports that were just build dependencies". > pkg autoremove > Thanks for that Mathieu - I didn't know about that one. However... When I run it, it tells me that it's going to remove my cyrus-SASL port. I installed that (via its port) so that I can use SSL/TLS authentication on my Dovecot server (installed via the dovecot2 port). So Cyrus is not a build dependency of anything - why is it offering to remove it? Thanks, Graham ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
On 6/10/2016 8:20 AM, Mathieu Arnold wrote: Le 05/10/2016 à 22:04, Julian Elischer a écrit : Another thing that might be good woudl be a way to tell ports "remove all the ports that were just build dependencies". pkg autoremove Thanks for that Mathieu - I didn't know about that one. However... When I run it, it tells me that it's going to remove my cyrus-SASL port. I installed that (via its port) so that I can use SSL/TLS authentication on my Dovecot server (installed via the dovecot2 port). So Cyrus is not a build dependency of anything - why is it offering to remove it? Thanks, Graham ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
On 5/10/2016 2:20 PM, Mathieu Arnold wrote: Le 05/10/2016 à 22:04, Julian Elischer a écrit : Another thing that might be good woudl be a way to tell ports "remove all the ports that were just build dependencies". pkg autoremove hmm I didn't know that would remove build deps for packages that are still installed.. if so .. good! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
Le 05/10/2016 à 22:04, Julian Elischer a écrit : > Another thing that might be good woudl be a way to tell ports "remove > all the ports that were just build dependencies". pkg autoremove -- Mathieu Arnold signature.asc Description: OpenPGP digital signature
Re: dependency explosions
On 5/10/2016 1:39 PM, Miroslav Lachman wrote: Julian Elischer wrote on 10/05/2016 22:04: On 4/10/2016 11:38 PM, Mathieu Arnold wrote: Le 05/10/2016 à 05:18, Julian Elischer a écrit : On 3/10/2016 5:14 AM, Mathieu Arnold wrote: Le 01/10/2016 à 04:35, Julian Elischer a écrit : There is a need for a "minimum" install of a lot of packages. Some dependencies are often optional, and can be unchecked by running make config. Such a 'minimum' install should probably be the default when coming in as a dependency, as there is an increasing tendency to configure things with all the bells and whistles. The bare minimum will never be the default. The default is what will fit most people, so that they can use our packages out of the box. I didn't say it should be the default, I said it should be an easy to request option, (without using the config screen on each of 25000 ports) e.g. setting PORTS_CONFIG_MINIMUM before making everything. Most ports and packages are installed not because people want them, but because they are forced to do so by dependencies. Giving a way to reduce the number of unrequested packages, in a simple way would be of great use to many many people Feel free to open PR/provide patches for ports which you think need to provide more options. I think it would be a framework change. not so much a per-port change. By default, when the variable is set you take the list of options for the package, and set them all to 'unset'. The only packages that would need work would be those for which that is not a valid configuration, in which case you would supply some precanned list of options to set to unset (or similar) e.g. MIN_SETTINGS="bla foo bar" > the point is that if I'm including a port becuase it's just a prereq. then I probably want almost no options set.. The port itself can probably know what options are likely to be needed by things that need it adn can possibly supply a sensible setting but if it doesn't it might be possible to just do it automatically. It's ridiculous that a single small port can pull in python, perl and TCL (I forget which it was) along with some 40 or so other packages. There is one more problem - port A needs port B as dependency, port B can be compiled with 4 options [W,X,Y,Z], port A needs port B with option X which pull port C as dependency. So this needs to be set somewhere or else default minimal options would break some ports. any non-minimum port would trump a minimum port I would think. (and replace it?) it's just an idea. Born from frustration of not being able to do thigs because htey call in too many other things. If you call in too many other things the chance of one of them breaking gets higher. (approaches unity in some cases I think). Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
Julian Elischer wrote on 10/05/2016 22:04: On 4/10/2016 11:38 PM, Mathieu Arnold wrote: Le 05/10/2016 à 05:18, Julian Elischer a écrit : On 3/10/2016 5:14 AM, Mathieu Arnold wrote: Le 01/10/2016 à 04:35, Julian Elischer a écrit : There is a need for a "minimum" install of a lot of packages. Some dependencies are often optional, and can be unchecked by running make config. Such a 'minimum' install should probably be the default when coming in as a dependency, as there is an increasing tendency to configure things with all the bells and whistles. The bare minimum will never be the default. The default is what will fit most people, so that they can use our packages out of the box. I didn't say it should be the default, I said it should be an easy to request option, (without using the config screen on each of 25000 ports) e.g. setting PORTS_CONFIG_MINIMUM before making everything. Most ports and packages are installed not because people want them, but because they are forced to do so by dependencies. Giving a way to reduce the number of unrequested packages, in a simple way would be of great use to many many people Feel free to open PR/provide patches for ports which you think need to provide more options. I think it would be a framework change. not so much a per-port change. By default, when the variable is set you take the list of options for the package, and set them all to 'unset'. The only packages that would need work would be those for which that is not a valid configuration, in which case you would supply some precanned list of options to set to unset (or similar) e.g. MIN_SETTINGS="bla foo bar" > the point is that if I'm including a port becuase it's just a prereq. then I probably want almost no options set.. The port itself can probably know what options are likely to be needed by things that need it adn can possibly supply a sensible setting but if it doesn't it might be possible to just do it automatically. It's ridiculous that a single small port can pull in python, perl and TCL (I forget which it was) along with some 40 or so other packages. There is one more problem - port A needs port B as dependency, port B can be compiled with 4 options [W,X,Y,Z], port A needs port B with option X which pull port C as dependency. So this needs to be set somewhere or else default minimal options would break some ports. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
On 4/10/2016 11:38 PM, Mathieu Arnold wrote: Le 05/10/2016 à 05:18, Julian Elischer a écrit : On 3/10/2016 5:14 AM, Mathieu Arnold wrote: Le 01/10/2016 à 04:35, Julian Elischer a écrit : There is a need for a "minimum" install of a lot of packages. Some dependencies are often optional, and can be unchecked by running make config. Such a 'minimum' install should probably be the default when coming in as a dependency, as there is an increasing tendency to configure things with all the bells and whistles. The bare minimum will never be the default. The default is what will fit most people, so that they can use our packages out of the box. I didn't say it should be the default, I said it should be an easy to request option, (without using the config screen on each of 25000 ports) e.g. setting PORTS_CONFIG_MINIMUM before making everything. Most ports and packages are installed not because people want them, but because they are forced to do so by dependencies. Giving a way to reduce the number of unrequested packages, in a simple way would be of great use to many many people Feel free to open PR/provide patches for ports which you think need to provide more options. I think it would be a framework change. not so much a per-port change. By default, when the variable is set you take the list of options for the package, and set them all to 'unset'. The only packages that would need work would be those for which that is not a valid configuration, in which case you would supply some precanned list of options to set to unset (or similar) e.g. MIN_SETTINGS="bla foo bar" the point is that if I'm including a port becuase it's just a prereq. then I probably want almost no options set.. The port itself can probably know what options are likely to be needed by things that need it adn can possibly supply a sensible setting but if it doesn't it might be possible to just do it automatically. It's ridiculous that a single small port can pull in python, perl and TCL (I forget which it was) along with some 40 or so other packages. Another thing that might be good woudl be a way to tell ports "remove all the ports that were just build dependencies". ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
On 10/04/16 23:18, Julian Elischer wrote: > On 3/10/2016 5:14 AM, Mathieu Arnold wrote: >> [...] >> The bare minimum will never be the default. The default is what will >> fit most people, so that they can use our packages out of the box. >> > I didn't say it should be the default, I said it should be an easy to > request option, > (without using the config screen on each of 25000 ports) > e.g. setting PORTS_CONFIG_MINIMUM before making everything. > [...] +1! -- George ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
Le 05/10/2016 à 05:18, Julian Elischer a écrit : > On 3/10/2016 5:14 AM, Mathieu Arnold wrote: >> Le 01/10/2016 à 04:35, Julian Elischer a écrit : >>> There is a need for a "minimum" install of a lot of packages. >> Some dependencies are often optional, and can be unchecked by running >> make config. >> >>> Such a 'minimum' install should probably be the default when coming in >>> as a dependency, as >>> there is an increasing tendency to configure things with all the bells >>> and whistles. >> The bare minimum will never be the default. The default is what will >> fit most people, so that they can use our packages out of the box. >> > I didn't say it should be the default, I said it should be an easy to > request option, > (without using the config screen on each of 25000 ports) > e.g. setting PORTS_CONFIG_MINIMUM before making everything. > Most ports and packages are installed not because people want them, > but because they are forced to do so by dependencies. > Giving a way to reduce the number of unrequested packages, in a simple > way would be of great use to many many people Feel free to open PR/provide patches for ports which you think need to provide more options. -- Mathieu Arnold signature.asc Description: OpenPGP digital signature
Re: dependency explosions
On Tue, Oct 04, 2016 at 10:21:30AM +1100, Greg 'groggy' Lehey wrote: > Is there a way to display these dependencies in a tree structure? http://portsmon.freebsd.org/portdependencytree.py?category=x11&portname=kde4 It's slow because I do not store dependencies in the database, so it recalculates it on the fly. (disclaimer: I had to go fix it because it had bitrroted due to some kind of change in the make -V output somewhere.) mcl ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
On 3/10/2016 5:14 AM, Mathieu Arnold wrote: Le 01/10/2016 à 04:35, Julian Elischer a écrit : There is a need for a "minimum" install of a lot of packages. Some dependencies are often optional, and can be unchecked by running make config. Such a 'minimum' install should probably be the default when coming in as a dependency, as there is an increasing tendency to configure things with all the bells and whistles. The bare minimum will never be the default. The default is what will fit most people, so that they can use our packages out of the box. I didn't say it should be the default, I said it should be an easy to request option, (without using the config screen on each of 25000 ports) e.g. setting PORTS_CONFIG_MINIMUM before making everything. Most ports and packages are installed not because people want them, but because they are forced to do so by dependencies. Giving a way to reduce the number of unrequested packages, in a simple way would be of great use to many many people ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
Hi! > > The problem is to add code to allow variants is complex and needs > > engineering power. > But regarding the > changes that would be required to only allow other variants, why do you > say it would be complex? Wouldn't that be only a change in pkg so that > it can handle dependencies per set properly? It's my gut feeling, nothing more. I have not looked at the code of pkg or the ports framework. It's only that I'm playing around with dependency trees for the last quarter of a century, that's feeding my gut feeling here 8-} -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
On 04/10/2016 05:09, Kurt Jaeger wrote: Hi! Right now, we build packages for [9,10,11,12]x[amd64,i386]x[head,quarterly], that's 16 different sets, and we mostly manage to build them over and over again, every two days. Imagine how long it would take to build 320 sets. You are trying to take that into extreme to ridicule this as an option. I think the scenario that "if we had variants, other users would request other variants" is likely and the number of sets to build really would explode like that. It's not to ridicule that option. The problem is to add code to allow variants is complex and needs engineering power. OK, as I mentioned, I was wondering if that would be possible. So, apparently, it would, but would require changes in the code. Forget about other variants that users may want to propose - if they want other variants then they can take it on and maintain. But regarding the changes that would be required to only allow other variants, why do you say it would be complex? Wouldn't that be only a change in pkg so that it can handle dependencies per set properly? Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
Hi! > > Right now, we build packages for > > [9,10,11,12]x[amd64,i386]x[head,quarterly], that's 16 different sets, > > and we mostly manage to build them over and over again, every two days. > > Imagine how long it would take to build 320 sets. > You are trying to take that into extreme to ridicule this as an option. I think the scenario that "if we had variants, other users would request other variants" is likely and the number of sets to build really would explode like that. It's not to ridicule that option. The problem is to add code to allow variants is complex and needs engineering power. -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
On 3/10/2016 5:14 AM, Mathieu Arnold wrote: Le 01/10/2016 à 04:35, Julian Elischer a écrit : There is a need for a "minimum" install of a lot of packages. Some dependencies are often optional, and can be unchecked by running make config. but you can never really know the effect. there should be a use minimum environment variable and as I said, the minimum is usually what is required for build dependencies. And the minimum install may require less "other" packages thus reducing the explosion. Such a 'minimum' install should probably be the default when coming in as a dependency, as there is an increasing tendency to configure things with all the bells and whistles. The bare minimum will never be the default. The default is what will fit most people, so that they can use our packages out of the box. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
Greg 'groggy' Lehey wrote on 10/04/2016 01:21: [...] Chromium? Opera? Emacs? Both OpenOffice and LibreOffice? I don't know if this always happens, but there's an issue here. I have a few unfinished thoughts about how it could occur, but so far all I can confirm is that there is an issue. Is there a way to display these dependencies in a tree structure? You can use ports-mgmt/pkg_tree Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
On Monday, 3 October 2016 at 20:41:08 -0400, Baho Utot wrote: > > On 10/03/16 19:21, Greg 'groggy' Lehey wrote: >> On Monday, 3 October 2016 at 14:14:13 +0200, Mathieu Arnold wrote: >>> Le 01/10/2016 à 04:35, Julian Elischer a écrit : Such a 'minimum' install should probably be the default when coming in as a dependency, as there is an increasing tendency to configure things with all the bells and whistles. >>> The bare minimum will never be the default. The default is what will >>> fit most people, so that they can use our packages out of the box. >> Not necessarily disagreeing with you, but I recently installed a new >> version of firefox, and I was amazed by the number and nature of the >> dependencies. It totalled 497 MB, including: >> >>Fetching chromium-52.0.2743.116_1.txz: .. done >>Fetching opera-12.16_6.txz: .. done >>Fetching apache-openoffice-4.1.2_9.txz: .. done >>Fetching libreoffice-5.0.6_3.txz: .. done >>Fetching gimp-2.8.18,2.txz: . done >>Fetching hugin-2016.2.0.txz: .. done >>Fetching mplayer-1.3.0.20160912_1.txz: .. done >>Fetching samba42-4.2.14.txz: .. done >>Fetching emacs24-24.5_3,3.txz: .. done >> >> Chromium? Opera? Emacs? Both OpenOffice and LibreOffice? >> >> I don't know if this always happens, but there's an issue here. I >> have a few unfinished thoughts about how it could occur, but so far >> all I can confirm is that there is an issue. >> >> Is there a way to display these dependencies in a tree structure? > > $ make -C /usr/ports/www/firefox all-depends-list > /usr/ports/ports-mgmt/pkg > /usr/ports/devel/nspr > /usr/ports/devel/gmake > ... That isn't a tree. It also doesn't show the dependencies I mentioned above. And yes, I ran it locally. On reflection, it's probably because firefox requires an update to a library used by other packages, so they need to be upgraded too. Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA signature.asc Description: PGP signature
Re: dependency explosions
On 10/03/16 19:21, Greg 'groggy' Lehey wrote: On Monday, 3 October 2016 at 14:14:13 +0200, Mathieu Arnold wrote: Le 01/10/2016 à 04:35, Julian Elischer a écrit : Such a 'minimum' install should probably be the default when coming in as a dependency, as there is an increasing tendency to configure things with all the bells and whistles. The bare minimum will never be the default. The default is what will fit most people, so that they can use our packages out of the box. Not necessarily disagreeing with you, but I recently installed a new version of firefox, and I was amazed by the number and nature of the dependencies. It totalled 497 MB, including: Fetching chromium-52.0.2743.116_1.txz: .. done Fetching opera-12.16_6.txz: .. done Fetching apache-openoffice-4.1.2_9.txz: .. done Fetching libreoffice-5.0.6_3.txz: .. done Fetching gimp-2.8.18,2.txz: . done Fetching hugin-2016.2.0.txz: .. done Fetching mplayer-1.3.0.20160912_1.txz: .. done Fetching samba42-4.2.14.txz: .. done Fetching emacs24-24.5_3,3.txz: .. done Chromium? Opera? Emacs? Both OpenOffice and LibreOffice? I don't know if this always happens, but there's an issue here. I have a few unfinished thoughts about how it could occur, but so far all I can confirm is that there is an issue. Is there a way to display these dependencies in a tree structure? Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA $ make -C /usr/ports/www/firefox all-depends-list /usr/ports/ports-mgmt/pkg /usr/ports/devel/nspr /usr/ports/devel/gmake /usr/ports/devel/gettext-tools /usr/ports/converters/libiconv /usr/ports/devel/gettext-runtime /usr/ports/print/indexinfo /usr/ports/security/nss /usr/ports/archivers/zip /usr/ports/databases/sqlite3 /usr/ports/devel/ncurses /usr/ports/devel/pkgconf /usr/ports/devel/binutils /usr/ports/math/gmp /usr/ports/math/mpfr /usr/ports/devel/bison /usr/ports/devel/m4 /usr/ports/lang/perl5.20 /usr/ports/devel/libevent2 /usr/ports/devel/autoconf /usr/ports/misc/help2man /usr/ports/devel/p5-Locale-gettext /usr/ports/devel/autoconf-wrapper /usr/ports/devel/automake /usr/ports/devel/automake-wrapper /usr/ports/devel/libtool /usr/ports/audio/soundtouch /usr/ports/print/harfbuzz /usr/ports/devel/gobject-introspection /usr/ports/graphics/cairo /usr/ports/x11/xcb-util-renderutil /usr/ports/devel/xorg-macros /usr/ports/x11/libxcb /usr/ports/devel/libcheck /usr/ports/x11/xcb-proto /usr/ports/lang/python27 /usr/ports/devel/libffi /usr/ports/misc/dejagnu /usr/ports/lang/expect /usr/ports/lang/tcl86 /usr/ports/textproc/libxml2 /usr/ports/devel/libpthread-stubs /usr/ports/textproc/libxslt /usr/ports/security/libgcrypt /usr/ports/security/libgpg-error /usr/ports/x11/libXau /usr/ports/x11/xproto /usr/ports/x11/libXdmcp /usr/ports/x11/xcb-util /usr/ports/graphics/libGL /usr/ports/devel/makedepend /usr/ports/devel/libclc /usr/ports/devel/llvm37 /usr/ports/textproc/py-sphinx /usr/ports/devel/py-Jinja2 /usr/ports/devel/py-setuptools27 /usr/ports/textproc/py-MarkupSafe /usr/ports/devel/py-babel /usr/ports/devel/py-pytz /usr/ports/textproc/py-docutils /usr/ports/devel/py-six /usr/ports/devel/py-pytest /usr/ports/devel/py-py /usr/ports/devel/py-mock /usr/ports/devel/py-pbr /usr/ports/devel/py-pip /usr/ports/devel/py-pytest-capturelog /usr/ports/devel/py-pytest-timeout /usr/ports/devel/py-pytest-xdist /usr/ports/devel/py-setuptools_scm /usr/ports/sysutils/py-execnet /usr/ports/misc/py-pexpect /usr/ports/devel/py-virtualenv /usr/ports/devel/py-scripttest /usr/ports/devel/py-pretend /usr/ports/devel/py-freezegun /usr/ports/devel/py-dateutil /usr/ports/devel/py-nose /usr/ports/databases/py-sqlite3 /usr/ports/devel/git /usr/ports/textproc/xmlto /usr/ports/shells/bash /usr/ports/misc/getopt /usr/ports/textproc/docbook-xsl /usr/ports/textproc/xmlcatmgr /usr/ports/textproc/docbook /usr/ports/textproc/docbook-sgml /usr/ports/textproc/iso8879 /usr/ports/textproc/docbook-xml /usr/ports/textproc/xmlcharent /usr/ports/textproc/sdocbook-xml /usr/ports/print/libpaper /usr/ports/www/w3m /usr/ports/devel/boehm-gc /usr/ports/devel/libatomic_ops /usr/ports/textproc/asciidoc /usr/ports/lang/python2 /usr/ports/ftp/curl /usr/ports/security/ca_root_nss /usr/ports/lang/p5-Error /usr/ports/textproc/expat2 /usr/ports/devel/pcre /usr/ports/devel/cvsps /usr/ports/mail/p5-Net-SMTP-SSL /usr/ports/security/p5-IO-Socket-SSL /usr/ports/security/p5-Net-SSLeay /usr/ports/devel/p5-Test-Exception /usr/ports/devel/p5-Sub-Uplevel /usr/ports/devel/p5-Test-NoWarnings /usr/ports/devel/p5-Test-Simple /usr/ports/devel/p5-Test-Warn /usr/ports/www/p5-Mozilla-CA /usr/ports/net/p5-IO-Socket-IP /usr/ports/devel/p5-Test-Pod /usr/ports/net/p5-Socket /usr/ports/security/p5-Authen-SASL /usr/ports/security/p
Re: dependency explosions
On Monday, 3 October 2016 at 14:14:13 +0200, Mathieu Arnold wrote: > Le 01/10/2016 à 04:35, Julian Elischer a écrit : >> Such a 'minimum' install should probably be the default when coming >> in as a dependency, as there is an increasing tendency to configure >> things with all the bells and whistles. > > The bare minimum will never be the default. The default is what will > fit most people, so that they can use our packages out of the box. Not necessarily disagreeing with you, but I recently installed a new version of firefox, and I was amazed by the number and nature of the dependencies. It totalled 497 MB, including: Fetching chromium-52.0.2743.116_1.txz: .. done Fetching opera-12.16_6.txz: .. done Fetching apache-openoffice-4.1.2_9.txz: .. done Fetching libreoffice-5.0.6_3.txz: .. done Fetching gimp-2.8.18,2.txz: . done Fetching hugin-2016.2.0.txz: .. done Fetching mplayer-1.3.0.20160912_1.txz: .. done Fetching samba42-4.2.14.txz: .. done Fetching emacs24-24.5_3,3.txz: .. done Chromium? Opera? Emacs? Both OpenOffice and LibreOffice? I don't know if this always happens, but there's an issue here. I have a few unfinished thoughts about how it could occur, but so far all I can confirm is that there is an issue. Is there a way to display these dependencies in a tree structure? Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA signature.asc Description: PGP signature
Re: dependency explosions
Miroslav Lachman wrote on 10/03/2016 15:29: Grzegorz Junka wrote on 10/03/2016 15:11: On 03/10/2016 12:14, Mathieu Arnold wrote: Le 01/10/2016 à 04:35, Julian Elischer a écrit : There is a need for a "minimum" install of a lot of packages. Some dependencies are often optional, and can be unchecked by running make config. Such a 'minimum' install should probably be the default when coming in as a dependency, as there is an increasing tendency to configure things with all the bells and whistles. The bare minimum will never be the default. The default is what will fit most people, so that they can use our packages out of the box. Shouldn't all packages default to noX dependencies? If I am not mistaken FreeBSD is predominantly a server-side system, with X running only occasionally (I am running X but I compile all packages with poudriere). I agree. Many ports have X and -nox11 (like ImageMagick-nox11 or open-vm-tools-nox11) but there are still some without nox11 variant. But X11 is not the only one dependency problem. I think that dependency changes should be better tracked and examined before commit changes to ports tree. I am really tired of it. Now I realized that another port is unconditionally pulling hand full of new X11 dependecies which where not used before ant this was just PORTREVISION bump. Not new version with new functionality. When this will stop? # pkg info -r -d phantomjs-2.0.0_3 phantomjs-2.0.0_3 Depends on : fontconfig-2.12.1,1 png-1.6.23 icu-55.1,1 freetype2-2.6.3 jpeg-turbo-1.4.2 # pkg inf -r -d phantomjs-2.0.0_5 phantomjs-2.0.0_5 Depends on : fontconfig-2.12.1,1 png-1.6.23 libX11-1.6.3,1 freetype2-2.6.3 icu-57.1,1 jpeg-turbo-1.4.2 libX11 needs following packages xproto-7.0.28 libXdmcp-1.1.2 libpthread-stubs-0.3_6 libXau-1.0.8_3 libxcb-1.11.1 kbproto-1.0.7 Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
On 03/10/2016 14:48, Mathieu Arnold wrote: Le 03/10/2016 à 16:29, Grzegorz Junka a écrit : On 03/10/2016 14:11, Mike Clarke wrote: On Mon, 3 Oct 2016 13:11:43 + Grzegorz Junka wrote: Shouldn't all packages default to noX dependencies? If I am not mistaken FreeBSD is predominantly a server-side system, with X running only occasionally I'd disagree with that. I don't know whether or not the majority of FreeBSD installations are servers or personal computers but the chances are that the majority of server installations will have relatively few packages installed whereas most PC's are likely to make use of far more packages and are also likely to be using X. Building from ports to get the required options would be a much bigger task for these installations than it would be for the servers. I have been wondering if it would be possible to have two distinct set of packages compiled automatically, one tailored for X and one for the console. It seems that requirements of both environment are quite opposite. The server-side requires small amount of packages without X because it wants to run the system headless, as long as possible and without interruptions and restarts. Whereas the X/PC environment always wants to have everything latest and newest. In the Linux world they would just create a new distribution, even in the BSD world there is PC-BSD/TrueOS. But we have ports and can re-use the same base for two distinctive set of packages. I don't believe we can create pre-compiled packages for FreeBSD in such a way, that both camps are happy (which this thread is one of many signs of). The FreeBSD project cannot provide more than one set of packages. If we went that way, we would end up having to provide, say, [with X, without X]x[apache 2.2, apache 2.4]x[php56, php70]x[postgresql 9.3, 9.4, 9.5, 9.6]x[insert 5 flavors of mysql]x[openssl, libressl]... I'm sure I can find other kind of options, and that is already 320 sets. Right now, we build packages for [9,10,11,12]x[amd64,i386]x[head,quarterly], that's 16 different sets, and we mostly manage to build them over and over again, every two days. Imagine how long it would take to build 320 sets. You are trying to take that into extreme to ridicule this as an option. You can't possibly build 320 sets, even if you had enough build machines, because each set would need to contain incompatible packages. If you choose, say, php56 as the default, then you can't possibly install a package that depends on php70. The amount of combinations would expand exponentially. It would be like having 320 different incompatible sets of packages to test. The same with packages that depend on X. Sure, if you install emacs-nox11 you can still install other packages that depend on X, but at some point it would start to break, e.g. you wouldn't be able to install ImageMagick-nox11 and ImageMagick at the same time. What I proposed is to have two sets of packages, one for server use (noX, maybe other defaults) and one for desktop use (X, multimedia, maybe other defaults). You usually don't switch a machine that's working as a desktop workstation to suddenly become a rack server in some data center. Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
Le 03/10/2016 à 16:57, Matthieu Volat a écrit : > On Mon, 3 Oct 2016 14:29:27 + > Grzegorz Junka wrote: > >> On 03/10/2016 14:11, Mike Clarke wrote: >>> On Mon, 3 Oct 2016 13:11:43 + >>> Grzegorz Junka wrote: >>> Shouldn't all packages default to noX dependencies? If I am not mistaken FreeBSD is predominantly a server-side system, with X running only occasionally >>> I'd disagree with that. I don't know whether or not the majority of >>> FreeBSD installations are servers or personal computers but the chances >>> are that the majority of server installations will have relatively few >>> packages installed whereas most PC's are likely to make use of far >>> more packages and are also likely to be using X. Building from ports >>> to get the required options would be a much bigger task for these >>> installations than it would be for the servers. >>> >> I have been wondering if it would be possible to have two distinct set >> of packages compiled automatically, one tailored for X and one for the >> console. It seems that requirements of both environment are quite >> opposite. The server-side requires small amount of packages without X >> because it wants to run the system headless, as long as possible and >> without interruptions and restarts. Whereas the X/PC environment always >> wants to have everything latest and newest. In the Linux world they >> would just create a new distribution, even in the BSD world there is >> PC-BSD/TrueOS. But we have ports and can re-use the same base for two >> distinctive set of packages. I don't believe we can create pre-compiled >> packages for FreeBSD in such a way, that both camps are happy (which >> this thread is one of many signs of). >> >> Grzegorz > That must be somehow possible and even extensible to be something like > macports variants We have works in the pipes to do variants like package builds, yes, but the work is currently stalled because it breaks every tools we have. -- Mathieu Arnold signature.asc Description: OpenPGP digital signature
Re: dependency explosions
On Mon, 3 Oct 2016 14:29:27 + Grzegorz Junka wrote: > On 03/10/2016 14:11, Mike Clarke wrote: > > On Mon, 3 Oct 2016 13:11:43 + > > Grzegorz Junka wrote: > > > >> Shouldn't all packages default to noX dependencies? If I am not mistaken > >> FreeBSD is predominantly a server-side system, with X running only > >> occasionally > > I'd disagree with that. I don't know whether or not the majority of > > FreeBSD installations are servers or personal computers but the chances > > are that the majority of server installations will have relatively few > > packages installed whereas most PC's are likely to make use of far > > more packages and are also likely to be using X. Building from ports > > to get the required options would be a much bigger task for these > > installations than it would be for the servers. > > > > I have been wondering if it would be possible to have two distinct set > of packages compiled automatically, one tailored for X and one for the > console. It seems that requirements of both environment are quite > opposite. The server-side requires small amount of packages without X > because it wants to run the system headless, as long as possible and > without interruptions and restarts. Whereas the X/PC environment always > wants to have everything latest and newest. In the Linux world they > would just create a new distribution, even in the BSD world there is > PC-BSD/TrueOS. But we have ports and can re-use the same base for two > distinctive set of packages. I don't believe we can create pre-compiled > packages for FreeBSD in such a way, that both camps are happy (which > this thread is one of many signs of). > > Grzegorz That must be somehow possible and even extensible to be something like macports variants, except with binary package support (macports localy build packages when user defined option differs from default); but this would take signifiant space and processing power... On the other hand, setting OPTIONS_UNSET to include X11 is quite trivial. I would expect a server administrator to be more proficient in that kind of settings... PS. I agree with the multiplication of dependencies, but I see them as the result of nowaday FOSS ecosystem practices rather than port management issues. -- Matthieu Volat pgpE7Ij5qzGwY.pgp Description: OpenPGP digital signature
Re: dependency explosions
Le 03/10/2016 à 16:29, Grzegorz Junka a écrit : > > On 03/10/2016 14:11, Mike Clarke wrote: >> On Mon, 3 Oct 2016 13:11:43 + >> Grzegorz Junka wrote: >> >>> Shouldn't all packages default to noX dependencies? If I am not >>> mistaken >>> FreeBSD is predominantly a server-side system, with X running only >>> occasionally >> I'd disagree with that. I don't know whether or not the majority of >> FreeBSD installations are servers or personal computers but the chances >> are that the majority of server installations will have relatively few >> packages installed whereas most PC's are likely to make use of far >> more packages and are also likely to be using X. Building from ports >> to get the required options would be a much bigger task for these >> installations than it would be for the servers. >> > > I have been wondering if it would be possible to have two distinct set > of packages compiled automatically, one tailored for X and one for the > console. It seems that requirements of both environment are quite > opposite. The server-side requires small amount of packages without X > because it wants to run the system headless, as long as possible and > without interruptions and restarts. Whereas the X/PC environment > always wants to have everything latest and newest. In the Linux world > they would just create a new distribution, even in the BSD world there > is PC-BSD/TrueOS. But we have ports and can re-use the same base for > two distinctive set of packages. I don't believe we can create > pre-compiled packages for FreeBSD in such a way, that both camps are > happy (which this thread is one of many signs of). The FreeBSD project cannot provide more than one set of packages. If we went that way, we would end up having to provide, say, [with X, without X]x[apache 2.2, apache 2.4]x[php56, php70]x[postgresql 9.3, 9.4, 9.5, 9.6]x[insert 5 flavors of mysql]x[openssl, libressl]... I'm sure I can find other kind of options, and that is already 320 sets. Right now, we build packages for [9,10,11,12]x[amd64,i386]x[head,quarterly], that's 16 different sets, and we mostly manage to build them over and over again, every two days. Imagine how long it would take to build 320 sets. -- Mathieu Arnold signature.asc Description: OpenPGP digital signature
Re: dependency explosions
On 03/10/2016 14:11, Mike Clarke wrote: On Mon, 3 Oct 2016 13:11:43 + Grzegorz Junka wrote: Shouldn't all packages default to noX dependencies? If I am not mistaken FreeBSD is predominantly a server-side system, with X running only occasionally I'd disagree with that. I don't know whether or not the majority of FreeBSD installations are servers or personal computers but the chances are that the majority of server installations will have relatively few packages installed whereas most PC's are likely to make use of far more packages and are also likely to be using X. Building from ports to get the required options would be a much bigger task for these installations than it would be for the servers. I have been wondering if it would be possible to have two distinct set of packages compiled automatically, one tailored for X and one for the console. It seems that requirements of both environment are quite opposite. The server-side requires small amount of packages without X because it wants to run the system headless, as long as possible and without interruptions and restarts. Whereas the X/PC environment always wants to have everything latest and newest. In the Linux world they would just create a new distribution, even in the BSD world there is PC-BSD/TrueOS. But we have ports and can re-use the same base for two distinctive set of packages. I don't believe we can create pre-compiled packages for FreeBSD in such a way, that both camps are happy (which this thread is one of many signs of). Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
On Mon, 3 Oct 2016 13:11:43 + Grzegorz Junka wrote: > Shouldn't all packages default to noX dependencies? If I am not mistaken > FreeBSD is predominantly a server-side system, with X running only > occasionally I'd disagree with that. I don't know whether or not the majority of FreeBSD installations are servers or personal computers but the chances are that the majority of server installations will have relatively few packages installed whereas most PC's are likely to make use of far more packages and are also likely to be using X. Building from ports to get the required options would be a much bigger task for these installations than it would be for the servers. -- Mike Clarke ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
Grzegorz Junka wrote on 10/03/2016 15:11: On 03/10/2016 12:14, Mathieu Arnold wrote: Le 01/10/2016 à 04:35, Julian Elischer a écrit : There is a need for a "minimum" install of a lot of packages. Some dependencies are often optional, and can be unchecked by running make config. Such a 'minimum' install should probably be the default when coming in as a dependency, as there is an increasing tendency to configure things with all the bells and whistles. The bare minimum will never be the default. The default is what will fit most people, so that they can use our packages out of the box. Shouldn't all packages default to noX dependencies? If I am not mistaken FreeBSD is predominantly a server-side system, with X running only occasionally (I am running X but I compile all packages with poudriere). I agree. Many ports have X and -nox11 (like ImageMagick-nox11 or open-vm-tools-nox11) but there are still some without nox11 variant. But X11 is not the only one dependency problem. I think that dependency changes should be better tracked and examined before commit changes to ports tree. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
On 03/10/2016 12:14, Mathieu Arnold wrote: Le 01/10/2016 à 04:35, Julian Elischer a écrit : There is a need for a "minimum" install of a lot of packages. Some dependencies are often optional, and can be unchecked by running make config. Such a 'minimum' install should probably be the default when coming in as a dependency, as there is an increasing tendency to configure things with all the bells and whistles. The bare minimum will never be the default. The default is what will fit most people, so that they can use our packages out of the box. Shouldn't all packages default to noX dependencies? If I am not mistaken FreeBSD is predominantly a server-side system, with X running only occasionally (I am running X but I compile all packages with poudriere). --- Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: dependency explosions
Le 01/10/2016 à 04:35, Julian Elischer a écrit : > There is a need for a "minimum" install of a lot of packages. Some dependencies are often optional, and can be unchecked by running make config. > Such a 'minimum' install should probably be the default when coming in > as a dependency, as > there is an increasing tendency to configure things with all the bells > and whistles. The bare minimum will never be the default. The default is what will fit most people, so that they can use our packages out of the box. -- Mathieu Arnold signature.asc Description: OpenPGP digital signature
Re: dependency explosions
Julian Elischer wrote on 10/01/2016 04:35: Hi ports people. It seems to me that there has been an explosion in ports dependencies recently. Things that used to need a few dependencies are now pulling in things one would never imagine. We just had to add the openjdk7 port to something and the number of dependencies is at 120 and rising still. (mostly due to an *undocumented* dependency on a cups include file). I needed to add glib2 and I got over 20 dependencies. (and then it failed to compile). 12 ports I've been adding to my systems for years have now resulted in 135 unexpected ports being built. Some issues I've noted: There is a need for a "minimum" install of a lot of packages. Such a 'minimum' install should probably be the default when coming in as a dependency, as there is an increasing tendency to configure things with all the bells and whistles. anyone have any thought as to 1/ why the recent explosion, and 2/ what to do about it? Yes I have similar experience with last version of VirtualBox. We are using VirtualBox for a long time in headless mode. We have following unset in poudriers make.conf OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS VirtualBox was always built without GUI but new version has new option QT5 and this pulls many tens of unwanted dependency libraries. I don't understand why it pull anything for GUI if X11 is unset. I found that even QT5 radio box must be unset which is really unintuitive for me: │ │ [ ] X11 X11 (graphics) support │ │── GUI (Graphical User Interface) support │ │ ( ) QT4 Build with QT4 Frontend │ │+(*) QT5 Build with QT5 Frontend Radios are normally used for "choose one of them" especially in case one is preselected. So usually trivial update costs me a lot of time to solve this. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"