Re: manpath change for ports ?

[Tijl Coosemans]

On Fri, 21 Apr 2017 00:18:53 +0200 Mathieu Arnold  wrote:
> Le 21/04/2017 à 00:16, Baptiste Daroussin a écrit:
>> On Fri, Apr 21, 2017 at 12:13:52AM +0200, Mathieu Arnold wrote:
>>> I am waiting on an exp-run to fix this once and for all.
>>>
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067
>>>
>>> When that is committed, anything can be added to the path pkgconfig
>>> searches, ports will always install it in the right place.
>>
>> Sorry but why? why not moving libdata/pkgconfig to lib/pkgconfig? what
>> is the rationale?
>
> Because a lot of build software know that on FreeBSD, the .pc file go
> in libdata/pkgconfig. If we move to some other place, we'll have a
> USES=pathfixmore for the next 25 years until everyone understands we
> moved it some place else.

1. It's not a lot.  Certainly the amount of software that does not know
   about libdata is way bigger.
2. You don't need USES=pathfixmore, you just change the fixup target
   in your patch to move files in the other direction.  This fixup can
   then be removed in 25 years (less if you let it print a warning)
   while your fixup will have to be kept forever.
3. Proper porting of emulators/wine to amd64 requires building 32 bit
   versions of dependencies.  Their pkgconfig files would go to
   lib32/pkgconfig when configured with --libdir=${PREFIX}/lib32 while
   something like libdata/pkgconfig32 would require yet more patches
   and fixups.

Any difference from Linux makes porting work harder, so there should be
good reasons and there are none whatsoever to use libdata/pkgconfig over
lib/pkgconfig.  I really don't get why portmgr keeps blocking this
change every time it comes up in the past few years.
___
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: manpath change for ports ?

[Mathieu Arnold]

Le 21/04/2017 à 00:21, Baptiste Daroussin a écrit :
> On Fri, Apr 21, 2017 at 12:18:53AM +0200, Mathieu Arnold wrote:
>> Le 21/04/2017 à 00:16, Baptiste Daroussin a écrit :
>>> On Fri, Apr 21, 2017 at 12:13:52AM +0200, Mathieu Arnold wrote:
 Le 20/04/2017 à 23:21, Baptiste Daroussin a écrit :
> On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
>> On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
>>> Hi all,
>>>
>>> I would like to propose a change in the localbase hier for ports
>>>
>>> I think we should add /usr/local/share/man in the manpath along with
>>> at first
>>> and maybe instead of in long term.
>>>
>>> The reason is:
>>> - /usr/local/share/man seems more consistent to me with base which
>>> have:
>>>   /usr/share/man
>>> - It will remove lots of patches from the ports tree where were we
>>> need to patch
>>>   upstream build system to install in a non usual path.
>>>
>>> My proposal is to add to the manpath /usr/local/share/man in default
>>> man(1)
>>> command in FreeBSD 12 (MFCed to 11-STABLE)
>>>
>>> and either provide an errata for 11.0/10.3 or a
>>> /usr/local/etc/man.d/something.conf via a port or something like that
>>> for those
>>> two, what do you think?
>>>
>>> For the same reason I would like to allow porters to stop patching
>>> (with pathfix
>>> or anything else) the path for pkgconfig files and allow
>>> /usr/local/lib/pkgconfig along with the current
>>> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
>>>
>>> Which will also remove tons of hacks from the ports tree.
>>>
>>> What do you think?
>>>
>>> Best regards,
>>> Bapt
>> Hello,
>>
>> I recently committed the USES for the meson build system to ports. This
>> USES configures the meson build system with some default variables
>> which includes the location of the man pages. This setting is just a
>> flag to the meson command so it easy to change.
>>
>> Meson also handles the generation and installation of pkg-config files
>> that a port wants. The problem is that this is handled by the script
>> itself and there is no way to configure it, so we need to hack the
>> meson port to change it from lib/pkg-config to libdata/pkg-config like
>> we currently are using. (1) Or add a hack to meson.mk to move the pkg-
>> config to the right location (evil++ imho).
>>
>> My point I want to make is that currently there is only 1 port build
>> via the meson system (graphics/graphene). Should we change man/pkg-
>> config file locations now, it very easy. If we want to change them
>> later we will need to mass bump every meson build port. It is important
>> to note that GStreamer and GNOME are moving over to using meson instead
>> of autotools and that Wayland, Xorg en Mesa are exploring want is
>> needed to make the switch. So I think it important that the decision
>> what to do is done now and that we stick with it.
>>
>> Reading the rest of the thread it seems nobody is really against the
>> proposed change of man and pkg-config path's. So how does one submit a
>> policy change like this? I'm also not sure I'm the right person to push
>> this, I just got back from a break and I don't want to really deal with
>> something super high profile right away.
>>
>> -Koop
>>
>> (1) I would like to see lib/pkg-config back in the search path of
>> pkgconf since that means I don't have to do a crash course python
>> programming.
> Would be nice is portmgr can step on this, let's reduce this discussion 
> for now
> on pkgconf.
 I am waiting on an exp-run to fix this once and for all.

 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067

 When that is committed, anything can be added to the path pkgconfig
 searches, ports will always install it in the right place.

>>> Sorry but why? why not moving libdata/pkgconfig to lib/pkgconfig? what is 
>>> the
>>> rationale?
>> Because a lot of build software know that on FreeBSD, the .pc file go in
>> libdata/pkgconfig. If we move to some other place, we'll have a
>> USES=pathfixmore for the next 25 years until everyone understands we
>> moved it some place else.
>>
> ok a point for you there :)

I have no problems having lib/pkgconfig added to the search path so that
people who build stuff manually have their .pc files in a place where
pkg-config can read them, but I really do not want the ports to install
them in more than one place.
My PR solves that problem, all the ports will forcibly end up in
libdata/pkgconfig, we could even drop USES=pathfix.

-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: manpath change for ports ?

[Baptiste Daroussin]

On Fri, Apr 21, 2017 at 12:18:53AM +0200, Mathieu Arnold wrote:
> Le 21/04/2017 à 00:16, Baptiste Daroussin a écrit :
> > On Fri, Apr 21, 2017 at 12:13:52AM +0200, Mathieu Arnold wrote:
> >> Le 20/04/2017 à 23:21, Baptiste Daroussin a écrit :
> >>> On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
>  On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
> > Hi all,
> >
> > I would like to propose a change in the localbase hier for ports
> >
> > I think we should add /usr/local/share/man in the manpath along with
> > at first
> > and maybe instead of in long term.
> >
> > The reason is:
> > - /usr/local/share/man seems more consistent to me with base which
> > have:
> >   /usr/share/man
> > - It will remove lots of patches from the ports tree where were we
> > need to patch
> >   upstream build system to install in a non usual path.
> >
> > My proposal is to add to the manpath /usr/local/share/man in default
> > man(1)
> > command in FreeBSD 12 (MFCed to 11-STABLE)
> >
> > and either provide an errata for 11.0/10.3 or a
> > /usr/local/etc/man.d/something.conf via a port or something like that
> > for those
> > two, what do you think?
> >
> > For the same reason I would like to allow porters to stop patching
> > (with pathfix
> > or anything else) the path for pkgconfig files and allow
> > /usr/local/lib/pkgconfig along with the current
> > /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
> >
> > Which will also remove tons of hacks from the ports tree.
> >
> > What do you think?
> >
> > Best regards,
> > Bapt
>  Hello,
> 
>  I recently committed the USES for the meson build system to ports. This
>  USES configures the meson build system with some default variables
>  which includes the location of the man pages. This setting is just a
>  flag to the meson command so it easy to change.
> 
>  Meson also handles the generation and installation of pkg-config files
>  that a port wants. The problem is that this is handled by the script
>  itself and there is no way to configure it, so we need to hack the
>  meson port to change it from lib/pkg-config to libdata/pkg-config like
>  we currently are using. (1) Or add a hack to meson.mk to move the pkg-
>  config to the right location (evil++ imho).
> 
>  My point I want to make is that currently there is only 1 port build
>  via the meson system (graphics/graphene). Should we change man/pkg-
>  config file locations now, it very easy. If we want to change them
>  later we will need to mass bump every meson build port. It is important
>  to note that GStreamer and GNOME are moving over to using meson instead
>  of autotools and that Wayland, Xorg en Mesa are exploring want is
>  needed to make the switch. So I think it important that the decision
>  what to do is done now and that we stick with it.
> 
>  Reading the rest of the thread it seems nobody is really against the
>  proposed change of man and pkg-config path's. So how does one submit a
>  policy change like this? I'm also not sure I'm the right person to push
>  this, I just got back from a break and I don't want to really deal with
>  something super high profile right away.
> 
>  -Koop
> 
>  (1) I would like to see lib/pkg-config back in the search path of
>  pkgconf since that means I don't have to do a crash course python
>  programming.
> >>> Would be nice is portmgr can step on this, let's reduce this discussion 
> >>> for now
> >>> on pkgconf.
> >>
> >> I am waiting on an exp-run to fix this once and for all.
> >>
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067
> >>
> >> When that is committed, anything can be added to the path pkgconfig
> >> searches, ports will always install it in the right place.
> >>
> > Sorry but why? why not moving libdata/pkgconfig to lib/pkgconfig? what is 
> > the
> > rationale?
> Because a lot of build software know that on FreeBSD, the .pc file go in
> libdata/pkgconfig. If we move to some other place, we'll have a
> USES=pathfixmore for the next 25 years until everyone understands we
> moved it some place else.
> 
ok a point for you there :)

Bapt


signature.asc
Description: PGP signature

Re: manpath change for ports ?

[Mathieu Arnold]

Le 21/04/2017 à 00:16, Baptiste Daroussin a écrit :
> On Fri, Apr 21, 2017 at 12:13:52AM +0200, Mathieu Arnold wrote:
>> Le 20/04/2017 à 23:21, Baptiste Daroussin a écrit :
>>> On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
 On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
> Hi all,
>
> I would like to propose a change in the localbase hier for ports
>
> I think we should add /usr/local/share/man in the manpath along with
> at first
> and maybe instead of in long term.
>
> The reason is:
> - /usr/local/share/man seems more consistent to me with base which
> have:
>   /usr/share/man
> - It will remove lots of patches from the ports tree where were we
> need to patch
>   upstream build system to install in a non usual path.
>
> My proposal is to add to the manpath /usr/local/share/man in default
> man(1)
> command in FreeBSD 12 (MFCed to 11-STABLE)
>
> and either provide an errata for 11.0/10.3 or a
> /usr/local/etc/man.d/something.conf via a port or something like that
> for those
> two, what do you think?
>
> For the same reason I would like to allow porters to stop patching
> (with pathfix
> or anything else) the path for pkgconfig files and allow
> /usr/local/lib/pkgconfig along with the current
> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
>
> Which will also remove tons of hacks from the ports tree.
>
> What do you think?
>
> Best regards,
> Bapt
 Hello,

 I recently committed the USES for the meson build system to ports. This
 USES configures the meson build system with some default variables
 which includes the location of the man pages. This setting is just a
 flag to the meson command so it easy to change.

 Meson also handles the generation and installation of pkg-config files
 that a port wants. The problem is that this is handled by the script
 itself and there is no way to configure it, so we need to hack the
 meson port to change it from lib/pkg-config to libdata/pkg-config like
 we currently are using. (1) Or add a hack to meson.mk to move the pkg-
 config to the right location (evil++ imho).

 My point I want to make is that currently there is only 1 port build
 via the meson system (graphics/graphene). Should we change man/pkg-
 config file locations now, it very easy. If we want to change them
 later we will need to mass bump every meson build port. It is important
 to note that GStreamer and GNOME are moving over to using meson instead
 of autotools and that Wayland, Xorg en Mesa are exploring want is
 needed to make the switch. So I think it important that the decision
 what to do is done now and that we stick with it.

 Reading the rest of the thread it seems nobody is really against the
 proposed change of man and pkg-config path's. So how does one submit a
 policy change like this? I'm also not sure I'm the right person to push
 this, I just got back from a break and I don't want to really deal with
 something super high profile right away.

 -Koop

 (1) I would like to see lib/pkg-config back in the search path of
 pkgconf since that means I don't have to do a crash course python
 programming.
>>> Would be nice is portmgr can step on this, let's reduce this discussion for 
>>> now
>>> on pkgconf.
>>
>> I am waiting on an exp-run to fix this once and for all.
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067
>>
>> When that is committed, anything can be added to the path pkgconfig
>> searches, ports will always install it in the right place.
>>
> Sorry but why? why not moving libdata/pkgconfig to lib/pkgconfig? what is the
> rationale?
Because a lot of build software know that on FreeBSD, the .pc file go in
libdata/pkgconfig. If we move to some other place, we'll have a
USES=pathfixmore for the next 25 years until everyone understands we
moved it some place else.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: manpath change for ports ?

[Baptiste Daroussin]

On Fri, Apr 21, 2017 at 12:13:52AM +0200, Mathieu Arnold wrote:
> Le 20/04/2017 à 23:21, Baptiste Daroussin a écrit :
> > On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
> >> On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
> >>> Hi all,
> >>>
> >>> I would like to propose a change in the localbase hier for ports
> >>>
> >>> I think we should add /usr/local/share/man in the manpath along with
> >>> at first
> >>> and maybe instead of in long term.
> >>>
> >>> The reason is:
> >>> - /usr/local/share/man seems more consistent to me with base which
> >>> have:
> >>>   /usr/share/man
> >>> - It will remove lots of patches from the ports tree where were we
> >>> need to patch
> >>>   upstream build system to install in a non usual path.
> >>>
> >>> My proposal is to add to the manpath /usr/local/share/man in default
> >>> man(1)
> >>> command in FreeBSD 12 (MFCed to 11-STABLE)
> >>>
> >>> and either provide an errata for 11.0/10.3 or a
> >>> /usr/local/etc/man.d/something.conf via a port or something like that
> >>> for those
> >>> two, what do you think?
> >>>
> >>> For the same reason I would like to allow porters to stop patching
> >>> (with pathfix
> >>> or anything else) the path for pkgconfig files and allow
> >>> /usr/local/lib/pkgconfig along with the current
> >>> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
> >>>
> >>> Which will also remove tons of hacks from the ports tree.
> >>>
> >>> What do you think?
> >>>
> >>> Best regards,
> >>> Bapt
> >> Hello,
> >>
> >> I recently committed the USES for the meson build system to ports. This
> >> USES configures the meson build system with some default variables
> >> which includes the location of the man pages. This setting is just a
> >> flag to the meson command so it easy to change.
> >>
> >> Meson also handles the generation and installation of pkg-config files
> >> that a port wants. The problem is that this is handled by the script
> >> itself and there is no way to configure it, so we need to hack the
> >> meson port to change it from lib/pkg-config to libdata/pkg-config like
> >> we currently are using. (1) Or add a hack to meson.mk to move the pkg-
> >> config to the right location (evil++ imho).
> >>
> >> My point I want to make is that currently there is only 1 port build
> >> via the meson system (graphics/graphene). Should we change man/pkg-
> >> config file locations now, it very easy. If we want to change them
> >> later we will need to mass bump every meson build port. It is important
> >> to note that GStreamer and GNOME are moving over to using meson instead
> >> of autotools and that Wayland, Xorg en Mesa are exploring want is
> >> needed to make the switch. So I think it important that the decision
> >> what to do is done now and that we stick with it.
> >>
> >> Reading the rest of the thread it seems nobody is really against the
> >> proposed change of man and pkg-config path's. So how does one submit a
> >> policy change like this? I'm also not sure I'm the right person to push
> >> this, I just got back from a break and I don't want to really deal with
> >> something super high profile right away.
> >>
> >> -Koop
> >>
> >> (1) I would like to see lib/pkg-config back in the search path of
> >> pkgconf since that means I don't have to do a crash course python
> >> programming.
> > Would be nice is portmgr can step on this, let's reduce this discussion for 
> > now
> > on pkgconf.
> 
> 
> I am waiting on an exp-run to fix this once and for all.
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067
> 
> When that is committed, anything can be added to the path pkgconfig
> searches, ports will always install it in the right place.
> 
Sorry but why? why not moving libdata/pkgconfig to lib/pkgconfig? what is the
rationale?

Bapt


signature.asc
Description: PGP signature

Re: manpath change for ports ?

[Mathieu Arnold]

Le 20/04/2017 à 23:21, Baptiste Daroussin a écrit :
> On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
>> On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
>>> Hi all,
>>>
>>> I would like to propose a change in the localbase hier for ports
>>>
>>> I think we should add /usr/local/share/man in the manpath along with
>>> at first
>>> and maybe instead of in long term.
>>>
>>> The reason is:
>>> - /usr/local/share/man seems more consistent to me with base which
>>> have:
>>>   /usr/share/man
>>> - It will remove lots of patches from the ports tree where were we
>>> need to patch
>>>   upstream build system to install in a non usual path.
>>>
>>> My proposal is to add to the manpath /usr/local/share/man in default
>>> man(1)
>>> command in FreeBSD 12 (MFCed to 11-STABLE)
>>>
>>> and either provide an errata for 11.0/10.3 or a
>>> /usr/local/etc/man.d/something.conf via a port or something like that
>>> for those
>>> two, what do you think?
>>>
>>> For the same reason I would like to allow porters to stop patching
>>> (with pathfix
>>> or anything else) the path for pkgconfig files and allow
>>> /usr/local/lib/pkgconfig along with the current
>>> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
>>>
>>> Which will also remove tons of hacks from the ports tree.
>>>
>>> What do you think?
>>>
>>> Best regards,
>>> Bapt
>> Hello,
>>
>> I recently committed the USES for the meson build system to ports. This
>> USES configures the meson build system with some default variables
>> which includes the location of the man pages. This setting is just a
>> flag to the meson command so it easy to change.
>>
>> Meson also handles the generation and installation of pkg-config files
>> that a port wants. The problem is that this is handled by the script
>> itself and there is no way to configure it, so we need to hack the
>> meson port to change it from lib/pkg-config to libdata/pkg-config like
>> we currently are using. (1) Or add a hack to meson.mk to move the pkg-
>> config to the right location (evil++ imho).
>>
>> My point I want to make is that currently there is only 1 port build
>> via the meson system (graphics/graphene). Should we change man/pkg-
>> config file locations now, it very easy. If we want to change them
>> later we will need to mass bump every meson build port. It is important
>> to note that GStreamer and GNOME are moving over to using meson instead
>> of autotools and that Wayland, Xorg en Mesa are exploring want is
>> needed to make the switch. So I think it important that the decision
>> what to do is done now and that we stick with it.
>>
>> Reading the rest of the thread it seems nobody is really against the
>> proposed change of man and pkg-config path's. So how does one submit a
>> policy change like this? I'm also not sure I'm the right person to push
>> this, I just got back from a break and I don't want to really deal with
>> something super high profile right away.
>>
>> -Koop
>>
>> (1) I would like to see lib/pkg-config back in the search path of
>> pkgconf since that means I don't have to do a crash course python
>> programming.
> Would be nice is portmgr can step on this, let's reduce this discussion for 
> now
> on pkgconf.


I am waiting on an exp-run to fix this once and for all.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067

When that is committed, anything can be added to the path pkgconfig
searches, ports will always install it in the right place.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: manpath change for ports ?

[Baptiste Daroussin]

On Thu, Apr 20, 2017 at 11:18:14PM +0200, Koop Mast wrote:
> On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
> > Hi all,
> > 
> > I would like to propose a change in the localbase hier for ports
> > 
> > I think we should add /usr/local/share/man in the manpath along with
> > at first
> > and maybe instead of in long term.
> > 
> > The reason is:
> > - /usr/local/share/man seems more consistent to me with base which
> > have:
> >   /usr/share/man
> > - It will remove lots of patches from the ports tree where were we
> > need to patch
> >   upstream build system to install in a non usual path.
> > 
> > My proposal is to add to the manpath /usr/local/share/man in default
> > man(1)
> > command in FreeBSD 12 (MFCed to 11-STABLE)
> > 
> > and either provide an errata for 11.0/10.3 or a
> > /usr/local/etc/man.d/something.conf via a port or something like that
> > for those
> > two, what do you think?
> > 
> > For the same reason I would like to allow porters to stop patching
> > (with pathfix
> > or anything else) the path for pkgconfig files and allow
> > /usr/local/lib/pkgconfig along with the current
> > /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
> > 
> > Which will also remove tons of hacks from the ports tree.
> > 
> > What do you think?
> > 
> > Best regards,
> > Bapt
> 
> Hello,
> 
> I recently committed the USES for the meson build system to ports. This
> USES configures the meson build system with some default variables
> which includes the location of the man pages. This setting is just a
> flag to the meson command so it easy to change.
> 
> Meson also handles the generation and installation of pkg-config files
> that a port wants. The problem is that this is handled by the script
> itself and there is no way to configure it, so we need to hack the
> meson port to change it from lib/pkg-config to libdata/pkg-config like
> we currently are using. (1) Or add a hack to meson.mk to move the pkg-
> config to the right location (evil++ imho).
> 
> My point I want to make is that currently there is only 1 port build
> via the meson system (graphics/graphene). Should we change man/pkg-
> config file locations now, it very easy. If we want to change them
> later we will need to mass bump every meson build port. It is important
> to note that GStreamer and GNOME are moving over to using meson instead
> of autotools and that Wayland, Xorg en Mesa are exploring want is
> needed to make the switch. So I think it important that the decision
> what to do is done now and that we stick with it.
> 
> Reading the rest of the thread it seems nobody is really against the
> proposed change of man and pkg-config path's. So how does one submit a
> policy change like this? I'm also not sure I'm the right person to push
> this, I just got back from a break and I don't want to really deal with
> something super high profile right away.
> 
> -Koop
> 
> (1) I would like to see lib/pkg-config back in the search path of
> pkgconf since that means I don't have to do a crash course python
> programming.

Would be nice is portmgr can step on this, let's reduce this discussion for now
on pkgconf.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: manpath change for ports ?

[Koop Mast]

On Tue, 2017-03-07 at 00:56 +0100, Baptiste Daroussin wrote:
> Hi all,
> 
> I would like to propose a change in the localbase hier for ports
> 
> I think we should add /usr/local/share/man in the manpath along with
> at first
> and maybe instead of in long term.
> 
> The reason is:
> - /usr/local/share/man seems more consistent to me with base which
> have:
>   /usr/share/man
> - It will remove lots of patches from the ports tree where were we
> need to patch
>   upstream build system to install in a non usual path.
> 
> My proposal is to add to the manpath /usr/local/share/man in default
> man(1)
> command in FreeBSD 12 (MFCed to 11-STABLE)
> 
> and either provide an errata for 11.0/10.3 or a
> /usr/local/etc/man.d/something.conf via a port or something like that
> for those
> two, what do you think?
> 
> For the same reason I would like to allow porters to stop patching
> (with pathfix
> or anything else) the path for pkgconfig files and allow
> /usr/local/lib/pkgconfig along with the current
> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
> 
> Which will also remove tons of hacks from the ports tree.
> 
> What do you think?
> 
> Best regards,
> Bapt

Hello,

I recently committed the USES for the meson build system to ports. This
USES configures the meson build system with some default variables
which includes the location of the man pages. This setting is just a
flag to the meson command so it easy to change.

Meson also handles the generation and installation of pkg-config files
that a port wants. The problem is that this is handled by the script
itself and there is no way to configure it, so we need to hack the
meson port to change it from lib/pkg-config to libdata/pkg-config like
we currently are using. (1) Or add a hack to meson.mk to move the pkg-
config to the right location (evil++ imho).

My point I want to make is that currently there is only 1 port build
via the meson system (graphics/graphene). Should we change man/pkg-
config file locations now, it very easy. If we want to change them
later we will need to mass bump every meson build port. It is important
to note that GStreamer and GNOME are moving over to using meson instead
of autotools and that Wayland, Xorg en Mesa are exploring want is
needed to make the switch. So I think it important that the decision
what to do is done now and that we stick with it.

Reading the rest of the thread it seems nobody is really against the
proposed change of man and pkg-config path's. So how does one submit a
policy change like this? I'm also not sure I'm the right person to push
this, I just got back from a break and I don't want to really deal with
something super high profile right away.

-Koop

(1) I would like to see lib/pkg-config back in the search path of
pkgconf since that means I don't have to do a crash course python
programming.
___
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: manpath change for ports ?

[Baptiste Daroussin]

On Fri, Mar 10, 2017 at 10:50:39AM +0100, Dag-Erling Smørgrav wrote:
> John Baldwin  writes:
> > I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
> > so long as our default MANPATH included both if that means applying fewer
> > patches to ports.
> 
> The default MANPATH is constructed dynamically from PATH:
> 
>  1.   From each component of the user's PATH for the first of:
>   -   pathname/man
>   -   pathname/MAN
>   -   If pathname ends with /bin: pathname/../man
>   Note: Special logic exists to make /bin and /usr/bin look in
>   /usr/share/man for manual files.
> 
> If we change this to:
> 
>  1.   From each component of the user's PATH for the first of:
>   -   pathname/man
>   -   pathname/MAN
>   -   If pathname ends with /bin or /sbin: pathname/../man and
>   pathname/../share/man
Which I have just done :)

Bapt


signature.asc
Description: PGP signature

Re: manpath change for ports ?

[Tijl Coosemans]

On Fri, 10 Mar 2017 08:38:30 -0800 Steve Kargl 
 wrote:
> On Fri, Mar 10, 2017 at 05:03:08PM +0100, Tijl Coosemans wrote:
>> On Fri, 10 Mar 2017 10:50:39 +0100 Dag-Erling Smørgrav  wrote:  
>>> John Baldwin  writes:  
 I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
 so long as our default MANPATH included both if that means applying fewer
 patches to ports.
>>> 
>>> The default MANPATH is constructed dynamically from PATH:
>>> 
>>>  1.   From each component of the user's PATH for the first of:
>>>   -   pathname/man
>>>   -   pathname/MAN
>>>   -   If pathname ends with /bin: pathname/../man
>>>   Note: Special logic exists to make /bin and /usr/bin look in
>>>   /usr/share/man for manual files.
>>> 
>>> If we change this to:
>>> 
>>>  1.   From each component of the user's PATH for the first of:
>>>   -   pathname/man
>>>   -   pathname/MAN
>>>   -   If pathname ends with /bin or /sbin: pathname/../man and
>>>   pathname/../share/man
>>> 
>>> we wouldn't need any "special logic", but I really don't like the idea
>>> of having different ports installing man pages in different locations.  
>> 
>> I grepped the ports tree and found nearly 5700 ports.  That's a lot to
>> change all at once but it may be doable.  It depends on how much fallout
>> there is in the exp-run.  
> 
> ln -s /usr/local/share/man /usr/local/man
> 
> should cause the manpages to land where you want.  Then port
> maintainers can sweep ports/ to allow for the removal of symlink. 

Yeah, I had to deal with installing through symlinks in the Linux ports
because bin, lib and sbin have become symlinks there now.  There are
complications with that.  FreeBSD releases have a bug in libarchive that
causes problems when extracting hardlinks through symlinks.  Recent
versions of pkg have workarounds for that but not everybody runs it yet.
Before you can create the symlink you have to move the existing
directory, but what if the new directory already exists?  Will you
overwrite files?  Commands like pkg-which and pkg-delete only work
through the symlink because the new paths are not in the pkg database.
Packages that don't know about the symlink may try to create it as a
directory or remove it as a directory on uninstall.  I ended up avoiding
it at all costs in the Linux ports by moving files around in the staging
area if necessary.
___
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: manpath change for ports ?

[Steve Kargl]

On Fri, Mar 10, 2017 at 05:03:08PM +0100, Tijl Coosemans wrote:
> On Fri, 10 Mar 2017 10:50:39 +0100 Dag-Erling Smørgrav  wrote:
> > John Baldwin  writes:
> >> I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
> >> so long as our default MANPATH included both if that means applying fewer
> >> patches to ports.  
> > 
> > The default MANPATH is constructed dynamically from PATH:
> > 
> >  1.   From each component of the user's PATH for the first of:
> >   -   pathname/man
> >   -   pathname/MAN
> >   -   If pathname ends with /bin: pathname/../man
> >   Note: Special logic exists to make /bin and /usr/bin look in
> >   /usr/share/man for manual files.
> > 
> > If we change this to:
> > 
> >  1.   From each component of the user's PATH for the first of:
> >   -   pathname/man
> >   -   pathname/MAN
> >   -   If pathname ends with /bin or /sbin: pathname/../man and
> >   pathname/../share/man
> > 
> > we wouldn't need any "special logic", but I really don't like the idea
> > of having different ports installing man pages in different locations.
> 
> I grepped the ports tree and found nearly 5700 ports.  That's a lot to
> change all at once but it may be doable.  It depends on how much fallout
> there is in the exp-run.

ln -s /usr/local/share/man /usr/local/man

should cause the manpages to land where you want.  Then port
maintainers can sweep ports/ to allow for the removal of symlink. 

On a side note, it is unfortunate that one cannot set the
environmental variable MANPATH as documented without either
a mysterious vanishing of man pages or an idiotic warning
appear with each invocation of man, apropos, ... 

-- 
Steve
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
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: manpath change for ports ?

[Tijl Coosemans]

On Tue, 7 Mar 2017 00:56:10 +0100 Baptiste Daroussin  wrote:
> My proposal is to add to the manpath /usr/local/share/man in default
> man(1) command in FreeBSD 12 (MFCed to 11-STABLE)
> 
> and either provide an errata for 11.0/10.3 or a
> /usr/local/etc/man.d/something.conf via a port or something like that
> for those two, what do you think?

I don't think we can expect users to install the latest errata or to
run the latest head or stable, so a port would be needed.  Could the
pkg port be used for this?
___
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: manpath change for ports ?

[Tijl Coosemans]

On Fri, 10 Mar 2017 10:50:39 +0100 Dag-Erling Smørgrav  wrote:
> John Baldwin  writes:
>> I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
>> so long as our default MANPATH included both if that means applying fewer
>> patches to ports.  
> 
> The default MANPATH is constructed dynamically from PATH:
> 
>  1.   From each component of the user's PATH for the first of:
>   -   pathname/man
>   -   pathname/MAN
>   -   If pathname ends with /bin: pathname/../man
>   Note: Special logic exists to make /bin and /usr/bin look in
>   /usr/share/man for manual files.
> 
> If we change this to:
> 
>  1.   From each component of the user's PATH for the first of:
>   -   pathname/man
>   -   pathname/MAN
>   -   If pathname ends with /bin or /sbin: pathname/../man and
>   pathname/../share/man
> 
> we wouldn't need any "special logic", but I really don't like the idea
> of having different ports installing man pages in different locations.

I grepped the ports tree and found nearly 5700 ports.  That's a lot to
change all at once but it may be doable.  It depends on how much fallout
there is in the exp-run.

Ports are installed into a staging area now where files can be moved to
another location.  So a post-install make target could be added that
moves the man pages to share/man if necessary (and prints a warning to
maintainers in that case).  Then all pkg-plist and PLIST_FILES need to
be modified (with sed) and PORTREVISION needs to be bumped (also
scripted).

The same could be done to move info and pkgconfig files.
___
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: manpath change for ports ?

[Tijl Coosemans]

On Thu, 9 Mar 2017 19:43:05 -0600 Benjamin Kaduk  wrote:
> On Thu, Mar 09, 2017 at 12:35:32PM +0100, Tijl Coosemans wrote:
>> Note that -rpath /usr/local/lib isn't added by gcc but by libtool
>> because it assumes rtld will not search that directory automatically.
>> If you run './configure CC=gcc --prefix=/usr && make check' the tests
>> should succeed (without --enable-new-dtags) because -rpath isn't used
>> then.  
> 
> Sounds like a bug in the libtool packaging, then?

Rtld only searches /lib and /usr/lib.  It also searches the ldconfig
hints file and /usr/local/lib is there by default (ldconfig_paths in
/etc/defaults/rc.conf), but users are allowed to change that, for
instance when they install ports in another location than /usr/local.

Arguably, because our default compiler links with --enable-new-dtags,
gcc should as well, but because of the different run-time semantics of
DT_RPATH and DT_RUNPATH this is a potential minefield.  Upstream
binutils changed the default in ld once and this was quickly reverted.
___
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: manpath change for ports ?

[Dag-Erling Smørgrav]

John Baldwin  writes:
> I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
> so long as our default MANPATH included both if that means applying fewer
> patches to ports.

The default MANPATH is constructed dynamically from PATH:

 1.   From each component of the user's PATH for the first of:
  -   pathname/man
  -   pathname/MAN
  -   If pathname ends with /bin: pathname/../man
  Note: Special logic exists to make /bin and /usr/bin look in
  /usr/share/man for manual files.

If we change this to:

 1.   From each component of the user's PATH for the first of:
  -   pathname/man
  -   pathname/MAN
  -   If pathname ends with /bin or /sbin: pathname/../man and
  pathname/../share/man

we wouldn't need any "special logic", but I really don't like the idea
of having different ports installing man pages in different locations.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: manpath change for ports ?

[Benjamin Kaduk]

On Thu, Mar 09, 2017 at 12:35:32PM +0100, Tijl Coosemans wrote:
> Note that -rpath /usr/local/lib isn't added by gcc but by libtool
> because it assumes rtld will not search that directory automatically.
> If you run './configure CC=gcc --prefix=/usr && make check' the tests
> should succeed (without --enable-new-dtags) because -rpath isn't used
> then.

Sounds like a bug in the libtool packaging, then?

-Ben
___
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: manpath change for ports ?

[John Baldwin]

On Wednesday, March 08, 2017 04:39:50 PM Dag-Erling Smørgrav wrote:
> Baptiste Daroussin  writes:
> > I would like to propose a change in the localbase hier for ports
> >
> > I think we should add /usr/local/share/man in the manpath along with
> > at first and maybe instead of in long term.
> 
> 2) plus info -> share/info as suggested by jbeich
> 
> 3) plus libdata/pkgconfig -> lib/pkgconfig
> 
> These three items will ensure that "./configure --prefix=/usr/local &&
> make install" will do the right thing out of the box - by changing our
> definition of "the right thing" to match what the GNU autotools have
> been doing for at least 15 years.
> 
> 4) Remove the hardcoded library path in lang/gcc*
> 
> This makes it possible to work on software that includes both libraries
> and programs while an earlier copy of the same software is already
> installed.  With the current state of gcc, the programs you are working
> on will be linked against the version of the library that's already
> installed instead of the version you just compiled, and there is nothing
> you can do to prevent it.  You won't notice anything if all you ever do
> is "make && make install", because the new library will replace the old,
> but if you try to run your program directly from the build tree, it will
> use the wrong library.  This can be incredibly frustrating if you're not
> aware of it - imagine you're trying to fix a bug in that library and no
> matter what you do, your regression test keeps failing...

+1 on all these.  I think that ports compilers should not have
/usr/local/include or /usr/local/lib as implicit paths either as others
have stated.

I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
so long as our default MANPATH included both if that means applying fewer
patches to ports.

-- 
John Baldwin
___
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: manpath change for ports ?

[Anton Yuzhaninov]

On 03/06/17 18:56, Baptiste Daroussin wrote:

I think we should add /usr/local/share/man in the manpath along with at first
and maybe instead of in long term.

The reason is:
- /usr/local/share/man seems more consistent to me with base which have:
  /usr/share/man
- It will remove lots of patches from the ports tree where were we need to patch
  upstream build system to install in a non usual path.


1. During transition period having two trees for man pages - 
/usr/local/share/man and /usr/share/man will be additional headache.


2. When /usr/local/man will be removed some ports should be patched to 
use /usr/local/share/man instead /usr/local/man and we almost back to 
square one (with fewer ports to patch).


3. Patching man path is trivial comparing other challenges during 
porting software to FreeBSD. For me current situation with man path is 
not a big issue.


4. Linux Filesystem Hierarchy Standard has

/usr/share/man
but
/usr/local/man

Given all above I don't think this change is worth benefits it will have.

Also when/if you will add /usr/local/share/man, please submit patch to 
cmake:

https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/GNUInstallDirs.cmake#L273
Currently cmake defines CMAKE_INSTALL_MANDIR to $PREFIX/man on FreeBSD.

___
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: manpath change for ports ?

[Dimitry Andric]

On 9 Mar 2017, at 09:29, Dag-Erling Smørgrav  wrote:
...
> 1)
> 
> | I discovered that lang/gcc48 (and presumably the other gcc ports as
> | well) not only have /usr/local/include in their default include path,
> | but actually place it ahead of /usr/include.  This is causing me no end
> | of grief with software that uses iconv, because GNU libiconv's 
> | f*s up your namespace so the build fails unless you explicitly link with
> | GNU libiconv instead of using the libc version.  [...]
> 
> 2)
> 
> |  [...] I realized over the weekend that the
> | situation is even worse than I initially thought.  Basically, ports gcc
> | is unusable for any other purpose than to build ports which don't
> | support clang.  Let me explain with a hypothetical scenario:
> |
> | You are developing a library which is important enough that you need to
> | have the stable version installed on your development system.  It is
> | installed in /usr/local as usual.  You've been working on fixing a bug,
> | and have written a unit test which exercises the relevant code and
> | verified that it can deterministically trigger the bug.  You fix the bug
> | and 'make check' again, all green.  Then you clean out your working
> | copy, re-run configure with CC=gcc and 'make check' again.  Your tests
> | fail.
> |
> | What happened is that when you built your code with gcc, the tests were
> | linked and run with the stable version of the library, where the bug is
> | not fixed.  You can build with LDFLAGS=-L$(top_builddir)/lib, you can
> | even specify the full path to the library in LDADD for each individual
> | test, it doesn't matter.  It will *always* pick the installed version
> | first.  The only way to get your tests to pass is to not have the
> | library installed.

Please pin this email for re-use the next time a discussion is started
about adding /usr/local to the default include and library paths for the
base system compiler...  It's been more than a year now, so I expect
it to be regurgitated any time soon. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: manpath change for ports ?

[Dag-Erling Smørgrav]

Tijl Coosemans  writes:
> Right, to use libc iconv(3) with -I/usr/local/include and GNU libiconv
> installed you have to compile with -DLIBICONV_PLUG.

I didn't have -I/usr/local/include, gcc forced it on me.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: manpath change for ports ?

[Tijl Coosemans]

On Thu, 09 Mar 2017 09:29:42 +0100 Dag-Erling Smørgrav  wrote:
> Tijl Coosemans  writes:
>> If you want to run a program from its build directory and the program
>> links to a library also in the build directory then you have to run the
>> program with LD_LIBRARY_PATH environment variable set to the build
>> directory.  Or, you could link the program with -rpath , but
>> then you should relink it before installation.  It's one of the things
>> libtool takes care of automatically.
>>
>> If this is the problem you have then it has nothing to do with gcc.  If
>> you're not using libtool then your program probably does not have any
>> rpath or runpath so it falls back on rtld/ldconfig which may find it in
>> /usr/local/lib.  
> 
> You are correct in theory, but I am using libtool and it doesn't work.
> 
> Here's a series of emails I wrote to the maintainer a little over six
> months ago explaining the problem:
> 
> 1)
> 
> | I discovered that lang/gcc48 (and presumably the other gcc ports as
> | well) not only have /usr/local/include in their default include path,
> | but actually place it ahead of /usr/include.  This is causing me no end
> | of grief with software that uses iconv, because GNU libiconv's 
> | f*s up your namespace so the build fails unless you explicitly link with
> | GNU libiconv instead of using the libc version.  [...]

Right, to use libc iconv(3) with -I/usr/local/include and GNU libiconv
installed you have to compile with -DLIBICONV_PLUG.

> 2)
> 
> |  [...] I realized over the weekend that the
> | situation is even worse than I initially thought.  Basically, ports gcc
> | is unusable for any other purpose than to build ports which don't
> | support clang.  Let me explain with a hypothetical scenario:
> | 
> | You are developing a library which is important enough that you need to
> | have the stable version installed on your development system.  It is
> | installed in /usr/local as usual.  You've been working on fixing a bug,
> | and have written a unit test which exercises the relevant code and
> | verified that it can deterministically trigger the bug.  You fix the bug
> | and 'make check' again, all green.  Then you clean out your working
> | copy, re-run configure with CC=gcc and 'make check' again.  Your tests
> | fail.
> | 
> | What happened is that when you built your code with gcc, the tests were
> | linked and run with the stable version of the library, where the bug is
> | not fixed.  You can build with LDFLAGS=-L$(top_builddir)/lib, you can
> | even specify the full path to the library in LDADD for each individual
> | test, it doesn't matter.  It will *always* pick the installed version
> | first.  The only way to get your tests to pass is to not have the
> | library installed.
> | 
> | Real-world example - a 10.3 system with upstream OpenPAM installed
> | because it uses OpenPAM's OATH implementation:
> | 
> | with base clang:
> | 
> | des@desk ~/src/openpam/trunk% libtool exec ldd ./t/t_openpam_dispatch
> | /home/des/src/openpam/trunk/t/.libs/t_openpam_dispatch:
> | libpam.so.2 => /home/des/src/openpam/trunk/lib/libpam/.libs/libpam.so.2 
> (0x800822000)
> | liboath.so.2 => 
> /home/des/src/openpam/trunk/lib/liboath/.libs/liboath.so.2 (0x800a34000)
> | libcrypto.so.7 => /lib/libcrypto.so.7 (0x800c39000)
> | libc.so.7 => /lib/libc.so.7 (0x80102f000)
> | 
> | with lang/gcc:
> | 
> | des@desk ~/src/openpam/trunk% pkg which =gcc
> | /usr/local/bin/gcc was installed by package gcc-4.8.5_2
> | des@desk ~/src/openpam/trunk% libtool exec ldd ./t/t_openpam_dispatch
> | /home/des/src/openpam/trunk/t/.libs/t_openpam_dispatch:
> | libpam.so.2 => /usr/local/lib/libpam.so.2 (0x800822000)
> | liboath.so.2 => /usr/local/lib/liboath.so.2 (0x800a34000)
> | libcrypto.so.7 => /lib/libcrypto.so.7 (0x800c39000)
> | libc.so.7 => /lib/libc.so.7 (0x80102f000)
> | libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x8013dc000)
> | libthr.so.3 => /lib/libthr.so.3 (0x8017e9000)
> | 
> | (and don't ask me why the gcc version is linked with two different
> | versions of libcrypto!)

Here you can probably get things working by adding -Wl,--enable-new-dtags
to LDFLAGS in the configure script (or to AM_LDFLAGS in Makefile.am).
Clang runs ld(1) with this flag by default, gcc does not.  With clang the
program has DT_RUNPATH /usr/local/lib, which rtld(1) checks after
LD_LIBRARY_PATH, and with gcc the program has DT_RPATH /usr/local/lib which
rtld checks *before* LD_LIBRARY_PATH.

(The gold(1) linker also enables this flag by default.)

The reason it links to libcrypto twice is because liboath.so.2 pulls in
libcrypto.so.7 while gcc has linked libpam with libcrypto.so.8 because of
the implicit -L/usr/local/lib.

> 3)
> 
> | I honestly thought this was a recent change, but I realize now that the
> | recent change is that I switched from developing on systems that still
> | had gcc in base (without /usr/local in the 

Re: manpath change for ports ?

[scratch65535]

On Wed, 8 Mar 2017 20:47:31 -0800, Kevin Oberman
 wrote:

>On Wed, Mar 8, 2017 at 12:35 PM,  wrote:
>
>> On Tue, 7 Mar 2017 00:56:10 +0100, Baptiste Daroussin
>>  wrote:
>>
>> >Hi all,
>> >
>> >I would like to propose a change in the localbase hier for ports
>> >
>> >I think we should add /usr/local/share/man in the manpath along with at
>> first
>> >and maybe instead of in long term.
>> >
>> >The reason is:
>> >- /usr/local/share/man seems more consistent to me with base which have:
>> >  /usr/share/man
>> >- It will remove lots of patches from the ports tree where were we need
>> to patch
>> >  upstream build system to install in a non usual path.
>> >
>> >My proposal is to add to the manpath /usr/local/share/man in default
>> man(1)
>> >command in FreeBSD 12 (MFCed to 11-STABLE)
>> >
>> >and either provide an errata for 11.0/10.3 or a
>> >/usr/local/etc/man.d/something.conf via a port or something like that
>> for those
>> >two, what do you think?
>> >
>> >For the same reason I would like to allow porters to stop patching (with
>> pathfix
>> >or anything else) the path for pkgconfig files and allow
>> >/usr/local/lib/pkgconfig along with the current
>> >/usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
>> >
>> >Which will also remove tons of hacks from the ports tree.
>> >
>> >What do you think?
>> >
>> >Best regards,
>> >Bapt
>>
>> I would argue that the same principle should be followed with
>> *everything*:  if it's at or applies to the application level, it
>> should be in /usr/local/, no exceptions.
>>
>> And if that conflicts with the native product documentation (e.g.
>> MySQL, MariaDB), the local mods should be right up at the top of
>> the relevant man page, not on some special web site or in some
>> special documentation hiding in the weeds somewhere.  Nobody
>> should have to chase down necessary information; if the man pages
>> are the canonical documentation, then all the facts should be on
>> the man page.
>>
>> And if something is not at the application level, then perhaps
>> this is the right time and place to have a conversation about
>> whether there should be a separate subtree for the layer between
>> the apps and the kernel, too.
>>
>> The desire for long-term stability, predictability, and freedom
>> from bugs is not a joke or a wish for a pony.  It's a basic
>> sine-qua-non necessity for production-quality software,
>> especially servers.   Would splitting off the middle layer from
>> the kernel help or hinder that goal?  The question must be worth
>> a conversation, and the sooner the better.
>>
>
>Wait a second! I don't think Bapt or anyone else was suggesting that ports
>install in any part of the tree other than /usr/local. Tr-read what he said.
>
>The discussion is whether to move from /usr/local/man to
>/usr/local/share/man as well as other directories that normally in
>/usr/[share|info||libexe] under Linux systems.

I wasn't suggesting that Bapt or anyone was suggesting that,
honest.  

I'm only arguing for greater consistency and simplicity than is
now the case.

Anyone who looks at fbsd (unix) from a human-factors standpoint
sees an incoherent picture made up of the (joking-but-not-
really-funny) "a phd hack, three master's theses, and a thousand
undergraduate term projects".  It lacks integrity and simplicity,
and consequently is needlessly hard to use, hard to maintain,
hard to love, and impossible to promote to the larger world.

We shouldn't be doing *anything* for the sake of consistency with
linux.  No change should be made for any reason other than the
result would be obviously *better* from a human-factors
standpoint.  If that means we steal some stuff from linux, fine. 
But doing anything for the sake of being "more like linux" is
barking nuts!  Linux is already as much like linux as anything
can be, so if our only goal is to make fbsd "more like linux",
then let's just grab a copy of some linux distro and call it
fbsd.  Voila!, instant 100% linux compatibility with 99.999% less
work.  Everyone could relax!

But that would be a going-out-of-business strategy, and I'm
certainly not suggesting it seriously.

What we should be doing for real is moving toward *replacing*
linux AND windows.  Make *them* go obsolete by becoming
less-obnoxious and more understandable.  We're already sturdier.

And a nice first step would be to start cleaning up the craziness
in the tree by moving *all* the apps-layer stuff to /usr/local.
___
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: manpath change for ports ?

[Dag-Erling Smørgrav]

jbe...@freebsd.org (Jan Beich) writes:
> /usr/local is *the* default location according to GNU[1] and reinforced
> by FHS[2] which want it "safe from being overwritten when the system
> software is updated". Not on FreeBSD where site-local stuff like your
> example above and ports/packages trample on each other. NetBSD avoided
> the issue by moving /usr/local to /usr/pkg.

All correct, but I don't really see the relevance...

DE
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: manpath change for ports ?

[Dag-Erling Smørgrav]

Tijl Coosemans  writes:
> If you want to run a program from its build directory and the program
> links to a library also in the build directory then you have to run the
> program with LD_LIBRARY_PATH environment variable set to the build
> directory.  Or, you could link the program with -rpath , but
> then you should relink it before installation.  It's one of the things
> libtool takes care of automatically.
>
> If this is the problem you have then it has nothing to do with gcc.  If
> you're not using libtool then your program probably does not have any
> rpath or runpath so it falls back on rtld/ldconfig which may find it in
> /usr/local/lib.

You are correct in theory, but I am using libtool and it doesn't work.

Here's a series of emails I wrote to the maintainer a little over six
months ago explaining the problem:

1)

| I discovered that lang/gcc48 (and presumably the other gcc ports as
| well) not only have /usr/local/include in their default include path,
| but actually place it ahead of /usr/include.  This is causing me no end
| of grief with software that uses iconv, because GNU libiconv's 
| f*s up your namespace so the build fails unless you explicitly link with
| GNU libiconv instead of using the libc version.  [...]

2)

|  [...] I realized over the weekend that the
| situation is even worse than I initially thought.  Basically, ports gcc
| is unusable for any other purpose than to build ports which don't
| support clang.  Let me explain with a hypothetical scenario:
| 
| You are developing a library which is important enough that you need to
| have the stable version installed on your development system.  It is
| installed in /usr/local as usual.  You've been working on fixing a bug,
| and have written a unit test which exercises the relevant code and
| verified that it can deterministically trigger the bug.  You fix the bug
| and 'make check' again, all green.  Then you clean out your working
| copy, re-run configure with CC=gcc and 'make check' again.  Your tests
| fail.
| 
| What happened is that when you built your code with gcc, the tests were
| linked and run with the stable version of the library, where the bug is
| not fixed.  You can build with LDFLAGS=-L$(top_builddir)/lib, you can
| even specify the full path to the library in LDADD for each individual
| test, it doesn't matter.  It will *always* pick the installed version
| first.  The only way to get your tests to pass is to not have the
| library installed.
| 
| Real-world example - a 10.3 system with upstream OpenPAM installed
| because it uses OpenPAM's OATH implementation:
| 
| with base clang:
| 
| des@desk ~/src/openpam/trunk% libtool exec ldd ./t/t_openpam_dispatch
| /home/des/src/openpam/trunk/t/.libs/t_openpam_dispatch:
|   libpam.so.2 => /home/des/src/openpam/trunk/lib/libpam/.libs/libpam.so.2 
(0x800822000)
|   liboath.so.2 => 
/home/des/src/openpam/trunk/lib/liboath/.libs/liboath.so.2 (0x800a34000)
|   libcrypto.so.7 => /lib/libcrypto.so.7 (0x800c39000)
|   libc.so.7 => /lib/libc.so.7 (0x80102f000)
| 
| with lang/gcc:
| 
| des@desk ~/src/openpam/trunk% pkg which =gcc
| /usr/local/bin/gcc was installed by package gcc-4.8.5_2
| des@desk ~/src/openpam/trunk% libtool exec ldd ./t/t_openpam_dispatch
| /home/des/src/openpam/trunk/t/.libs/t_openpam_dispatch:
|   libpam.so.2 => /usr/local/lib/libpam.so.2 (0x800822000)
|   liboath.so.2 => /usr/local/lib/liboath.so.2 (0x800a34000)
|   libcrypto.so.7 => /lib/libcrypto.so.7 (0x800c39000)
|   libc.so.7 => /lib/libc.so.7 (0x80102f000)
|   libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x8013dc000)
|   libthr.so.3 => /lib/libthr.so.3 (0x8017e9000)
| 
| (and don't ask me why the gcc version is linked with two different
| versions of libcrypto!)

3)

| I honestly thought this was a recent change, but I realize now that the
| recent change is that I switched from developing on systems that still
| had gcc in base (without /usr/local in the search path) to systems that
| don't, and therefore use gcc from ports.
| 
| The correct solution, in my opinion, is to remove /usr/local from all
| search paths.  There is no need for it, even for ports, because most
| ports add /usr/local to CPPFLAGS and LDFLAGS, either explicitly or
| implicitly (by passing --prefix=${LOCALBASE} to the configure script).
| If there are gcc-only ports which *don't* do it, they can easily be
| fixed.
| 
| I initially thought that merely changing the library search order would
| be sufficient, but apparently gcc somehow forces /usr/local/lib to take
| precedence even over ${LD_LIBRARY_PATH}, which is what causes my unit
| tests to fail.  Here is an example from another project where I modified
| the libtool wrapper to show its environment and run ldd before executing
| the binary:
| 
| des@desk ~/src/cryb-to% ./t/t_core
| 
PATH=/home/des/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
| 

Re: manpath change for ports ?

[Kevin Oberman]

On Wed, Mar 8, 2017 at 12:35 PM,  wrote:

> On Tue, 7 Mar 2017 00:56:10 +0100, Baptiste Daroussin
>  wrote:
>
> >Hi all,
> >
> >I would like to propose a change in the localbase hier for ports
> >
> >I think we should add /usr/local/share/man in the manpath along with at
> first
> >and maybe instead of in long term.
> >
> >The reason is:
> >- /usr/local/share/man seems more consistent to me with base which have:
> >  /usr/share/man
> >- It will remove lots of patches from the ports tree where were we need
> to patch
> >  upstream build system to install in a non usual path.
> >
> >My proposal is to add to the manpath /usr/local/share/man in default
> man(1)
> >command in FreeBSD 12 (MFCed to 11-STABLE)
> >
> >and either provide an errata for 11.0/10.3 or a
> >/usr/local/etc/man.d/something.conf via a port or something like that
> for those
> >two, what do you think?
> >
> >For the same reason I would like to allow porters to stop patching (with
> pathfix
> >or anything else) the path for pkgconfig files and allow
> >/usr/local/lib/pkgconfig along with the current
> >/usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
> >
> >Which will also remove tons of hacks from the ports tree.
> >
> >What do you think?
> >
> >Best regards,
> >Bapt
>
> I would argue that the same principle should be followed with
> *everything*:  if it's at or applies to the application level, it
> should be in /usr/local/, no exceptions.
>
> And if that conflicts with the native product documentation (e.g.
> MySQL, MariaDB), the local mods should be right up at the top of
> the relevant man page, not on some special web site or in some
> special documentation hiding in the weeds somewhere.  Nobody
> should have to chase down necessary information; if the man pages
> are the canonical documentation, then all the facts should be on
> the man page.
>
> And if something is not at the application level, then perhaps
> this is the right time and place to have a conversation about
> whether there should be a separate subtree for the layer between
> the apps and the kernel, too.
>
> The desire for long-term stability, predictability, and freedom
> from bugs is not a joke or a wish for a pony.  It's a basic
> sine-qua-non necessity for production-quality software,
> especially servers.   Would splitting off the middle layer from
> the kernel help or hinder that goal?  The question must be worth
> a conversation, and the sooner the better.
>

Wait a second! I don't think Bapt or anyone else was suggesting that ports
install in any part of the tree other than /usr/local. Tr-read what he said.

The discussion is whether to move from /usr/local/man to
/usr/local/share/man as well as other directories that normally in
/usr/[share|info||libexe] under Linux systems.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: manpath change for ports ?

[scratch65535]

On Tue, 7 Mar 2017 00:56:10 +0100, Baptiste Daroussin
 wrote:

>Hi all,
>
>I would like to propose a change in the localbase hier for ports
>
>I think we should add /usr/local/share/man in the manpath along with at first
>and maybe instead of in long term.
>
>The reason is:
>- /usr/local/share/man seems more consistent to me with base which have:
>  /usr/share/man
>- It will remove lots of patches from the ports tree where were we need to 
>patch
>  upstream build system to install in a non usual path.
>
>My proposal is to add to the manpath /usr/local/share/man in default man(1)
>command in FreeBSD 12 (MFCed to 11-STABLE)
>
>and either provide an errata for 11.0/10.3 or a
>/usr/local/etc/man.d/something.conf via a port or something like that for those
>two, what do you think?
>
>For the same reason I would like to allow porters to stop patching (with 
>pathfix
>or anything else) the path for pkgconfig files and allow
>/usr/local/lib/pkgconfig along with the current
>/usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
>
>Which will also remove tons of hacks from the ports tree.
>
>What do you think?
>
>Best regards,
>Bapt

I would argue that the same principle should be followed with
*everything*:  if it's at or applies to the application level, it
should be in /usr/local/, no exceptions.  

And if that conflicts with the native product documentation (e.g.
MySQL, MariaDB), the local mods should be right up at the top of
the relevant man page, not on some special web site or in some
special documentation hiding in the weeds somewhere.  Nobody
should have to chase down necessary information; if the man pages
are the canonical documentation, then all the facts should be on
the man page.

And if something is not at the application level, then perhaps
this is the right time and place to have a conversation about
whether there should be a separate subtree for the layer between
the apps and the kernel, too. 

The desire for long-term stability, predictability, and freedom
from bugs is not a joke or a wish for a pony.  It's a basic
sine-qua-non necessity for production-quality software,
especially servers.   Would splitting off the middle layer from
the kernel help or hinder that goal?  The question must be worth
a conversation, and the sooner the better. 

___
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: manpath change for ports ?

[Tijl Coosemans]

On Wed, 8 Mar 2017 10:31:32 -0700 Warner Losh  wrote:
> On Wed, Mar 8, 2017 at 10:21 AM, Tijl Coosemans  wrote:
>> Are you talking about gcc implicitly searching /usr/local/include and
>> /usr/local/lib?  
> 
> That's currently inconsistent between base gcc, clang, binutils and
> ports versions. I forget which ones do and which ones don't search
> automatically.

It's only ports binutils and ports gcc that search /usr/local.

> IMHO, they all should.

I used to think this too, but now I think it should be possible to use
any compiler to compile something from base or something that should only
depend on things from base, for testing purposes or perhaps because it
needs to be deployed on some other machine.  Compilers shouldn't search
/usr/local implicitly then.  It's easy enough to add -I and -L flags
(perhaps using pkg-config) but it's not easy to remove built-in -I and
-L flags.
___
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: manpath change for ports ?

[Tijl Coosemans]

On Wed, 08 Mar 2017 16:39:50 +0100 Dag-Erling Smørgrav  wrote:
> 4) Remove the hardcoded library path in lang/gcc*
> 
> This makes it possible to work on software that includes both libraries
> and programs while an earlier copy of the same software is already
> installed.  With the current state of gcc, the programs you are working
> on will be linked against the version of the library that's already
> installed instead of the version you just compiled, and there is nothing
> you can do to prevent it.  You won't notice anything if all you ever do
> is "make && make install", because the new library will replace the old,
> but if you try to run your program directly from the build tree, it will
> use the wrong library.  This can be incredibly frustrating if you're not
> aware of it - imagine you're trying to fix a bug in that library and no
> matter what you do, your regression test keeps failing...

If you want to run a program from its build directory and the program
links to a library also in the build directory then you have to run the
program with LD_LIBRARY_PATH environment variable set to the build
directory.  Or, you could link the program with -rpath , but
then you should relink it before installation.  It's one of the things
libtool takes care of automatically.

If this is the problem you have then it has nothing to do with gcc.  If
you're not using libtool then your program probably does not have any
rpath or runpath so it falls back on rtld/ldconfig which may find it in
/usr/local/lib.
___
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: manpath change for ports ?

[Jan Beich]

Dag-Erling Smørgrav  writes:

> Baptiste Daroussin  writes:
>
>> I would like to propose a change in the localbase hier for ports
>>
>> I think we should add /usr/local/share/man in the manpath along with
>> at first and maybe instead of in long term.
>
> 2) plus info -> share/info as suggested by jbeich
>
> 3) plus libdata/pkgconfig -> lib/pkgconfig
>
> These three items will ensure that "./configure --prefix=/usr/local &&
> make install" will do the right thing out of the box - by changing our
> definition of "the right thing" to match what the GNU autotools have
> been doing for at least 15 years.

/usr/local is *the* default location according to GNU[1] and reinforced
by FHS[2] which want it "safe from being overwritten when the system
software is updated". Not on FreeBSD where site-local stuff like your
example above and ports/packages trample on each other. NetBSD avoided
the issue by moving /usr/local to /usr/pkg.

[1] https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
[2] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
___
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: manpath change for ports ?

[Warner Losh]

On Wed, Mar 8, 2017 at 10:21 AM, Tijl Coosemans  wrote:
> On Wed, 08 Mar 2017 16:39:50 +0100 Dag-Erling Smørgrav  wrote:
>> 4) Remove the hardcoded library path in lang/gcc*
>>
>> This makes it possible to work on software that includes both libraries
>> and programs while an earlier copy of the same software is already
>> installed.  With the current state of gcc, the programs you are working
>> on will be linked against the version of the library that's already
>> installed instead of the version you just compiled, and there is nothing
>> you can do to prevent it.  You won't notice anything if all you ever do
>> is "make && make install", because the new library will replace the old,
>> but if you try to run your program directly from the build tree, it will
>> use the wrong library.  This can be incredibly frustrating if you're not
>> aware of it - imagine you're trying to fix a bug in that library and no
>> matter what you do, your regression test keeps failing...
>
> Are you talking about gcc implicitly searching /usr/local/include and
> /usr/local/lib?

That's currently inconsistent between base gcc, clang, binutils and
ports versions. I forget which ones do and which ones don't search
automatically. IMHO, they all should.

Warner
___
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: manpath change for ports ?

[Tijl Coosemans]

On Wed, 08 Mar 2017 16:39:50 +0100 Dag-Erling Smørgrav  wrote:
> 4) Remove the hardcoded library path in lang/gcc*
> 
> This makes it possible to work on software that includes both libraries
> and programs while an earlier copy of the same software is already
> installed.  With the current state of gcc, the programs you are working
> on will be linked against the version of the library that's already
> installed instead of the version you just compiled, and there is nothing
> you can do to prevent it.  You won't notice anything if all you ever do
> is "make && make install", because the new library will replace the old,
> but if you try to run your program directly from the build tree, it will
> use the wrong library.  This can be incredibly frustrating if you're not
> aware of it - imagine you're trying to fix a bug in that library and no
> matter what you do, your regression test keeps failing...

Are you talking about gcc implicitly searching /usr/local/include and
/usr/local/lib?
___
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: manpath change for ports ?

[Dag-Erling Smørgrav]

Julian Elischer  writes:
> Dag-Erling Smørgrav  writes:
> > This makes it possible to work on software that includes both
> > libraries and programs while an earlier copy of the same software is
> > already installed.  With the current state of gcc, the programs you
> > are working on will be linked against the version of the library
> > that's already installed instead of the version you just compiled,
> > and there is nothing
> unless you use --sysroot=...

Sure, if you have a copy of every single library your project depends on
in your build tree.

Is it really unreasonable to expect this to work out of the box?

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: manpath change for ports ?

[Julian Elischer]

On 8/3/17 11:39 pm, Dag-Erling Smørgrav wrote:

Baptiste Daroussin  writes:

I would like to propose a change in the localbase hier for ports

I think we should add /usr/local/share/man in the manpath along with
at first and maybe instead of in long term.

2) plus info -> share/info as suggested by jbeich

3) plus libdata/pkgconfig -> lib/pkgconfig

These three items will ensure that "./configure --prefix=/usr/local &&
make install" will do the right thing out of the box - by changing our
definition of "the right thing" to match what the GNU autotools have
been doing for at least 15 years.

4) Remove the hardcoded library path in lang/gcc*

This makes it possible to work on software that includes both libraries
and programs while an earlier copy of the same software is already
installed.  With the current state of gcc, the programs you are working
on will be linked against the version of the library that's already
installed instead of the version you just compiled, and there is nothing

unless you use --sysroot=...

you can do to prevent it.  You won't notice anything if all you ever do
is "make && make install", because the new library will replace the old,
but if you try to run your program directly from the build tree, it will
use the wrong library.  This can be incredibly frustrating if you're not
aware of it - imagine you're trying to fix a bug in that library and no
matter what you do, your regression test keeps failing...

DES



___
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: manpath change for ports ?

[Dag-Erling Smørgrav]

Baptiste Daroussin  writes:
> I would like to propose a change in the localbase hier for ports
>
> I think we should add /usr/local/share/man in the manpath along with
> at first and maybe instead of in long term.

2) plus info -> share/info as suggested by jbeich

3) plus libdata/pkgconfig -> lib/pkgconfig

These three items will ensure that "./configure --prefix=/usr/local &&
make install" will do the right thing out of the box - by changing our
definition of "the right thing" to match what the GNU autotools have
been doing for at least 15 years.

4) Remove the hardcoded library path in lang/gcc*

This makes it possible to work on software that includes both libraries
and programs while an earlier copy of the same software is already
installed.  With the current state of gcc, the programs you are working
on will be linked against the version of the library that's already
installed instead of the version you just compiled, and there is nothing
you can do to prevent it.  You won't notice anything if all you ever do
is "make && make install", because the new library will replace the old,
but if you try to run your program directly from the build tree, it will
use the wrong library.  This can be incredibly frustrating if you're not
aware of it - imagine you're trying to fix a bug in that library and no
matter what you do, your regression test keeps failing...

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
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: manpath change for ports ?

[Renato Botelho]

On 07/03/17 12:24, Diane Bruce wrote:
> On Tue, Mar 07, 2017 at 06:29:19AM +, Jan Beich wrote:
>> Baptiste Daroussin  writes:
>>
>>> Hi all,
>>>
>>> I would like to propose a change in the localbase hier for ports
>>>
>>> I think we should add /usr/local/share/man in the manpath along with at 
>>> first
>>> and maybe instead of in long term.
>>>
>>> The reason is:
>>> - /usr/local/share/man seems more consistent to me with base which have:
>>>   /usr/share/man
>>> - It will remove lots of patches from the ports tree where were we need to 
>>> patch
>>>   upstream build system to install in a non usual path.
>> Can you also move /usr/local/info to /usr/local/share/info? texinfo is
>> gone since 11.0-RELEASE (or r276551) but hier(7) and BSD.usr.dist still
>> try to encroach on GNU defaults.
> A big yes from me for both of these proposals. 
>

+1

-- 
Renato Botelho

___
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: manpath change for ports ?

[Tijl Coosemans]

On Tue, 7 Mar 2017 09:51:14 -0600 Eric van Gyzen  wrote:
> On 03/06/2017 17:56, Baptiste Daroussin wrote:
>> I would like to propose a change in the localbase hier for ports  
> 
> [...]
> 
>> Which will also remove tons of hacks from the ports tree.
>>
>> What do you think?  
> 
> This sounds good to me.
> 
> I seem to recall that most(?) Linux distros used /usr/man many years 
> ago, but they switched to /usr/share/man, I think in the early 2000s. 
> If that's correct, then I consider our /usr/local/man path a historical 
> curiosity that should finally be changed to /usr/local/share/man.

Yes, we used PREFIX/man because that's what software developed for
Linux used at the time.
___
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: manpath change for ports ?

[Chris H]

On Tue, 7 Mar 2017 00:56:10 +0100 Baptiste Daroussin  wrote

> Hi all,
> 
> I would like to propose a change in the localbase hier for ports
> 
> I think we should add /usr/local/share/man in the manpath along with at first
> and maybe instead of in long term.
> 
> The reason is:
> - /usr/local/share/man seems more consistent to me with base which have:
>   /usr/share/man
> - It will remove lots of patches from the ports tree where were we need to
> patch   upstream build system to install in a non usual path.
> 
> My proposal is to add to the manpath /usr/local/share/man in default man(1)
> command in FreeBSD 12 (MFCed to 11-STABLE)
> 
> and either provide an errata for 11.0/10.3 or a
> /usr/local/etc/man.d/something.conf via a port or something like that for
> those two, what do you think?
> 
> For the same reason I would like to allow porters to stop patching (with
> pathfix or anything else) the path for pkgconfig files and allow
> /usr/local/lib/pkgconfig along with the current
> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
> 
> Which will also remove tons of hacks from the ports tree.
> 
> What do you think?
+1 please do.
I can't think of any (good) reason not to.

Thanks!

--Chris
> 
> Best regards,
> Bapt


___
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: manpath change for ports ?

[Eric van Gyzen]

On 03/06/2017 17:56, Baptiste Daroussin wrote:

Hi all,

I would like to propose a change in the localbase hier for ports


[...]


Which will also remove tons of hacks from the ports tree.

What do you think?


This sounds good to me.

I seem to recall that most(?) Linux distros used /usr/man many years 
ago, but they switched to /usr/share/man, I think in the early 2000s. 
If that's correct, then I consider our /usr/local/man path a historical 
curiosity that should finally be changed to /usr/local/share/man.


Eric
___
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: manpath change for ports ?

[Diane Bruce]

On Tue, Mar 07, 2017 at 06:29:19AM +, Jan Beich wrote:
> Baptiste Daroussin  writes:
> 
> > Hi all,
> >
> > I would like to propose a change in the localbase hier for ports
> >
> > I think we should add /usr/local/share/man in the manpath along with at 
> > first
> > and maybe instead of in long term.
> >
> > The reason is:
> > - /usr/local/share/man seems more consistent to me with base which have:
> >   /usr/share/man
> > - It will remove lots of patches from the ports tree where were we need to 
> > patch
> >   upstream build system to install in a non usual path.
> 
> Can you also move /usr/local/info to /usr/local/share/info? texinfo is
> gone since 11.0-RELEASE (or r276551) but hier(7) and BSD.usr.dist still
> try to encroach on GNU defaults.

A big yes from me for both of these proposals. 

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: manpath change for ports ?

[Baptiste Daroussin]

On Tue, Mar 07, 2017 at 06:29:19AM +, Jan Beich wrote:
> Baptiste Daroussin  writes:
> 
> > Hi all,
> >
> > I would like to propose a change in the localbase hier for ports
> >
> > I think we should add /usr/local/share/man in the manpath along with at 
> > first
> > and maybe instead of in long term.
> >
> > The reason is:
> > - /usr/local/share/man seems more consistent to me with base which have:
> >   /usr/share/man
> > - It will remove lots of patches from the ports tree where were we need to 
> > patch
> >   upstream build system to install in a non usual path.
> 
> Can you also move /usr/local/info to /usr/local/share/info? texinfo is
> gone since 11.0-RELEASE (or r276551) but hier(7) and BSD.usr.dist still
> try to encroach on GNU defaults.

Yes would be a good one

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: manpath change for ports ?

[Jan Beich]

Baptiste Daroussin  writes:

> Hi all,
>
> I would like to propose a change in the localbase hier for ports
>
> I think we should add /usr/local/share/man in the manpath along with at first
> and maybe instead of in long term.
>
> The reason is:
> - /usr/local/share/man seems more consistent to me with base which have:
>   /usr/share/man
> - It will remove lots of patches from the ports tree where were we need to 
> patch
>   upstream build system to install in a non usual path.

Can you also move /usr/local/info to /usr/local/share/info? texinfo is
gone since 11.0-RELEASE (or r276551) but hier(7) and BSD.usr.dist still
try to encroach on GNU defaults.
___
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: manpath change for ports ?

[Alfred Perlstein]

On 3/6/17 3:56 PM, Baptiste Daroussin wrote:

Hi all,

I would like to propose a change in the localbase hier for ports

I think we should add /usr/local/share/man in the manpath along with at first
and maybe instead of in long term.

The reason is:
- /usr/local/share/man seems more consistent to me with base which have:
   /usr/share/man
- It will remove lots of patches from the ports tree where were we need to patch
   upstream build system to install in a non usual path.

My proposal is to add to the manpath /usr/local/share/man in default man(1)
command in FreeBSD 12 (MFCed to 11-STABLE)

and either provide an errata for 11.0/10.3 or a
/usr/local/etc/man.d/something.conf via a port or something like that for those
two, what do you think?

For the same reason I would like to allow porters to stop patching (with pathfix
or anything else) the path for pkgconfig files and allow
/usr/local/lib/pkgconfig along with the current
/usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig

Which will also remove tons of hacks from the ports tree.

What do you think?

Best regards,
Bapt
Yes please.  Reducing the required changes to port software to FreeBSD 
is a good thing.


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

manpath change for ports ?

[Baptiste Daroussin]

Hi all,

I would like to propose a change in the localbase hier for ports

I think we should add /usr/local/share/man in the manpath along with at first
and maybe instead of in long term.

The reason is:
- /usr/local/share/man seems more consistent to me with base which have:
  /usr/share/man
- It will remove lots of patches from the ports tree where were we need to patch
  upstream build system to install in a non usual path.

My proposal is to add to the manpath /usr/local/share/man in default man(1)
command in FreeBSD 12 (MFCed to 11-STABLE)

and either provide an errata for 11.0/10.3 or a
/usr/local/etc/man.d/something.conf via a port or something like that for those
two, what do you think?

For the same reason I would like to allow porters to stop patching (with pathfix
or anything else) the path for pkgconfig files and allow
/usr/local/lib/pkgconfig along with the current
/usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig

Which will also remove tons of hacks from the ports tree.

What do you think?

Best regards,
Bapt


signature.asc
Description: PGP signature