Re: dependency explosions

[Graham Menhennitt]

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

[Matthew Seaman]

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

[Miroslav Lachman]

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

[Graham Menhennitt]

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

[Graham Menhennitt]

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

[Graham Menhennitt]

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

[Julian Elischer]

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

[Mathieu Arnold]

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

[Julian Elischer]

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

[Miroslav Lachman]

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

[Julian Elischer]

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

[George Mitchell]

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

[Mathieu Arnold]

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

[Mark Linimon]

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=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

[Julian Elischer]

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

[Kurt Jaeger]

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

[Grzegorz Junka]

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

[Kurt Jaeger]

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

[Julian Elischer]

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

[Miroslav Lachman]

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

[Greg 'groggy' Lehey]

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

[Baho Utot]

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

Re: dependency explosions

[Greg 'groggy' Lehey]

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]

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

[Grzegorz Junka]

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

[Mathieu Arnold]

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

[Matthieu Volat]

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

[Mathieu Arnold]

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

[Grzegorz Junka]

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

[Mike Clarke]

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

[Miroslav Lachman]

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

[Grzegorz Junka]

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

[Mathieu Arnold]

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

[Miroslav Lachman]

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"

dependency explosions

[Julian Elischer]

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?


___
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"