tech@mandoc.bsd.lv
 help / color / mirror / Atom feed
* Allow configure variables to be set from environment
@ 2015-01-16 21:58 ` Alexis
  2015-01-16 23:32   ` Thomas Klausner
  2015-01-17  1:07   ` Ingo Schwarze
  0 siblings, 2 replies; 15+ messages in thread
From: Alexis @ 2015-01-16 21:58 UTC (permalink / raw)
  To: tech

Hello all,
I have written a Hombrew¹ formula² for mdocml, so OS X users
can install and use mdocml.

In order to adhere to the best practices in Homebrew I propose
the diff below, so that certain variables like PREFIX,
BINDIR, etc. can be changed by simply setting them in the
environment and without needing to edit configure, e.g.:
  % PREFIX=/opt/local ./configure

If there is another way to achieve this please let me know.


Best,
Alexis

¹ http://brew.sh - a package manager for OS X
² https://github.com/afh/homebrew/blob/pull/mdocml/Library/Formula/mdocml.rb

Index: configure
===================================================================
RCS file: /cvs/mdocml/configure,v
retrieving revision 1.17
diff -r1.17 configure
66,72c66,72
< PREFIX="/usr/local"
< BINDIR=
< SBINDIR=
< INCLUDEDIR=
< LIBDIR=
< MANDIR=
< EXAMPLEDIR=
---
> PREFIX="${PREFIX:-/usr/local}"
> BINDIR=${BINDIR}
> SBINDIR=${SBINDIR}
> INCLUDEDIR=${INCLUDEDIR}
> LIBDIR=${LIBDIR}
> MANDIR=${MANDIR}
> EXAMPLEDIR=${EXAMPLEDIR}

--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-16 21:58 ` Allow configure variables to be set from environment Alexis
@ 2015-01-16 23:32   ` Thomas Klausner
  2015-01-17  1:31     ` Ingo Schwarze
  2015-01-17  1:07   ` Ingo Schwarze
  1 sibling, 1 reply; 15+ messages in thread
From: Thomas Klausner @ 2015-01-16 23:32 UTC (permalink / raw)
  To: tech; +Cc: Alexis

On Fri, Jan 16, 2015 at 10:58:40PM +0100, Alexis wrote:
> If there is another way to achieve this please let me know.

Just set them on the 'make' command line, i.e.

make BINDIR=${BINDIR} PREFIX=${PREFIX} ...
 Thomas

P.S.: pkgsrc contains mdocml and supports OS X. Sorry, just had to mention that :)
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-16 21:58 ` Allow configure variables to be set from environment Alexis
  2015-01-16 23:32   ` Thomas Klausner
@ 2015-01-17  1:07   ` Ingo Schwarze
  2015-01-17 20:10     ` Kristaps Dzonsons
  2015-01-20 15:19     ` Alexis
  1 sibling, 2 replies; 15+ messages in thread
From: Ingo Schwarze @ 2015-01-17  1:07 UTC (permalink / raw)
  To: Alexis; +Cc: tech

Hi Alexis,

Alexis wrote on Fri, Jan 16, 2015 at 10:58:40PM +0100:

> I have written a Hombrew

Urgs.  That symlinking business is just ridiculous, especially
when it comes to manuals.  I strongly advise against using homebrew,
it just doesn't work.  For example, mandoc(1) denies following
symlinks outside the respective manual tree for security reasons.

I admit i don't speak ruby, but your script looks wrong.
You have to run "make" as non-root and "make install" as root.
I don't see how your script is doing that.

> formula for mdocml, so OS X users can install and use mdocml.

Why is the OS X ecosystem *that* fragmented?  Now we have three OS
X ports.  One completely outdated (at Macports), one using a package
manager that is broken by design, and the best one - using pkgsrc -
maintained externally by NetBSD.

Having one official port provided officially by the operating system
developers would clearly be preferable.  Can you try to talk them
into that, maybe providing code to them that they just have to verify
and commit?  That would really be helpful!

> In order to adhere to the best practices in Homebrew I propose
> the diff below, so that certain variables like PREFIX,
> BINDIR, etc. can be changed by simply setting them in the
> environment

I intentionally do not trust the environment, it might contain
god knows what I would never dream of somebody might put there
and the user would never dream of that i might look at.
I strongly resent environment variables in general.  On the
one hand, we are all into object oriented programming, on the
other hand, people make stuff so global that it's not even
clear which applications it applies to.

When building *one* program, you certainly don't need to make
your settings completely global, or feed completely global stuff
into it.

> and without needing to edit configure, e.g.:
>   % PREFIX=/opt/local ./configure

You shouldn't edit configure, the recommended way is to
put your settings into configure.local, see INSTALL and
configure.local.example for instructions and examples.

> If there is another way to achieve this please let me know.
> 
> 9 http://brew.sh - a package manager for OS X
> 2 https://github.com/afh/homebrew/blob/pull/mdocml/Library/Formula/mdocml.rb

For now, i have linked the pull request from

  http://mdocml.bsd.lv/ports.html
  http://mdocml.bsd.lv/porthistory.html

In case it gets merged to

  https://github.com/Homebrew/homebrew

please tell me to update the link.

Thanks,
  Ingo


> Index: configure
> ===================================================================
> RCS file: /cvs/mdocml/configure,v
> retrieving revision 1.17
> diff -r1.17 configure
> 66,72c66,72
> < PREFIX="/usr/local"
> < BINDIR=
> < SBINDIR=
> < INCLUDEDIR=
> < LIBDIR=
> < MANDIR=
> < EXAMPLEDIR=
> ---
> > PREFIX="${PREFIX:-/usr/local}"
> > BINDIR=${BINDIR}
> > SBINDIR=${SBINDIR}
> > INCLUDEDIR=${INCLUDEDIR}
> > LIBDIR=${LIBDIR}
> > MANDIR=${MANDIR}
> > EXAMPLEDIR=${EXAMPLEDIR}
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-16 23:32   ` Thomas Klausner
@ 2015-01-17  1:31     ` Ingo Schwarze
  0 siblings, 0 replies; 15+ messages in thread
From: Ingo Schwarze @ 2015-01-17  1:31 UTC (permalink / raw)
  To: Thomas Klausner; +Cc: tech, Alexis

Hi Thomas,

Thomas Klausner wrote on Sat, Jan 17, 2015 at 12:32:04AM +0100:
> On Fri, Jan 16, 2015 at 10:58:40PM +0100, Alexis wrote:

>> If there is another way to achieve this please let me know.

> Just set them on the 'make' command line, i.e.
> make BINDIR=${BINDIR} PREFIX=${PREFIX} ...

That is fragile at best.  With respect to *DIR, that might work
for now, because ./configure doesn't use the *DIR variables for
anything but to write them into Makefile.local.  But that is an
accident, in principle, ./configure might use them for something
else, too, so putting them into ./configure.local is certainly
more robust.

With respect to PREFIX, your advice doesn't even work.
Try

  make -n PREFIX=FOO install

and it says

  install -m 0555 mandoc demandoc /usr/local/bin

Oops.

That's because the main Makefile does not use PREFIX.
It relies on ./configure to assemble *DIR from PREFIX.

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-17  1:07   ` Ingo Schwarze
@ 2015-01-17 20:10     ` Kristaps Dzonsons
  2015-01-18  3:33       ` Ingo Schwarze
  2015-01-20 15:19     ` Alexis
  1 sibling, 1 reply; 15+ messages in thread
From: Kristaps Dzonsons @ 2015-01-17 20:10 UTC (permalink / raw)
  To: tech, Alexis

Alexis,

Ingo's right on this one, but let's think a bit more.  There are a lot 
of OS X people out there and a lot of them use homebrew.  I think it's 
worthwhile to have (or at least consider having) an official mandoc in 
homebrew, but it should be done right.  Doing a naive installation isn't 
enough.

The problem, as mentioned, is that makewhatis(8) won't pick up any 
homebrew manuals, making mandoc(1) only useful as a standalone binary 
operating directly on manpages (e.g., mandoc path/to/manpage.1).

You can patch makewhatis(8) not to check if the manpage is looking at 
symlinks outside of the MANPATH, but that's effectively opening up a 
security hole where mandoc(1) tools might be run on basically anything. 
  (By the way, did you plan on cron'ing makewhatis(8) or anything?)

If you don't patch makewhatis(8) and install it as-is, you're going to 
confuse users when their manpages don't show up when using the other 
tools installed with the package (apropos, man, etc.) or when running 
the respective mandoc arguments (-a, -f, etc.).

So either you patch makewhatis(8) or patch the installation to *only* 
install mandoc, then patch mandoc to omit -f, -k, and -a, and not 
respond to being invoked as apropos, whatis, or man.

Essentially, the question is whether you want mandoc as a constellation 
of tools (a man replacement) with security tools or a developer tool.

I don't know what the correct solution is here.  Bref, homebrew has issues.

Best,

Kristaps
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-17 20:10     ` Kristaps Dzonsons
@ 2015-01-18  3:33       ` Ingo Schwarze
  2015-01-20 15:15         ` Alexis
  0 siblings, 1 reply; 15+ messages in thread
From: Ingo Schwarze @ 2015-01-18  3:33 UTC (permalink / raw)
  To: Alexis; +Cc: tech, Kristaps Dzonsons

Hi Alexis, hi Kristaps,

Kristaps Dzonsons wrote on Sat, Jan 17, 2015 at 09:10:10PM +0100:

> Ingo's right on this one, but let's think a bit more.  There are a
> lot of OS X people out there and a lot of them use homebrew.  I
> think it's worthwhile to have (or at least consider having) an
> official mandoc in homebrew,

Thank you for clarifying that.  That's precisely how i feel, but
indeed i didn't make that clear.  When something annoys me, i'm
sometimes a bit brusque.

> but it should be done right.  Doing a naive installation isn't enough.
> 
> The problem, as mentioned, is that makewhatis(8) won't pick up any
> homebrew manuals, making mandoc(1) only useful as a standalone
> binary operating directly on manpages (e.g., mandoc path/to/manpage.1).

Exactly.

> You can patch makewhatis(8) not to check if the manpage is looking
> at symlinks outside of the MANPATH, but that's effectively opening
> up a security hole where mandoc(1) tools might be run on basically
> anything.

I'd thoroughly hate that.  If you do that, i will remove all reference
to your port from the homepage, and if need be, publish a statement
that you deliberately patch vulnerabilities into software you are
porting, urging people to not use your work.

> (By the way, did you plan on cron'ing makewhatis(8) or anything?)
> 
> If you don't patch makewhatis(8) and install it as-is, you're going
> to confuse users when their manpages don't show up when using the
> other tools installed with the package (apropos, man, etc.) or when
> running the respective mandoc arguments (-a, -f, etc.).
> 
> So either you patch makewhatis(8) or patch the installation to
> *only* install mandoc, then patch mandoc to omit -f, -k, and -a, and
> not respond to being invoked as apropos, whatis, or man.

No patching is needed.  Just set BUILD_DB=0 in configure.local,
it cleanly does all Kristaps is describing.

If you do that, it would be honest to add a note to the port that
people read when they install that mandoc can't be used as a
man(1) replacement with homebrew *because homebrew has security
issues*.  Make it clear that the security issues lay with
homebrew, *not with mandoc*, and that *any* other man(1) they
might install *is likely to either have the same security issues
or not work for the same reasons as mandoc*.

Oh wait a minute.  I think i see a solution.  If we specifically
allow mandoc to follow symlinks only into the homebrew tree, but
nowhere else, that seems safe.  It's a bit tricky to avoid race
conditions, but i think there is a secure way to implement it.  Is
there are standardized place where homebrew installs its real files,
and where nobody in their right mind would ever put any confidential
data?  Maybe /Cellar?  Is that right?

If you can confirm that, i might add official /Cellar support
to mandoc.

> Essentially, the question is whether you want mandoc as a
> constellation of tools (a man replacement) with security tools
> or a developer tool.

If you are a user of homebrew, you can ask the question even more
pointedly:  Do you want your system to be able to securely show
manual pages, even to a user logged in as a superuser, for example
root or any other high-privileged user having read access to
confidential files - the problem might arise even for regular
users if they own files that are in any way confidential, which
may even be a problem for their own files in their own home
directory, depending on the attack scenario.

If you want to securely show manuals installed by homebrew with
*any* implementation of man(1), more is needed than a port of
some random man(1) implementation.

> I don't know what the correct solution is here.
> Bref, homebrew has issues.

True, but the above might be a solution.  If we manage to support
that, it would actually be a safe man(1) for homebrew, much safer
than the traditional BSD or man-db implementations.

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-18  3:33       ` Ingo Schwarze
@ 2015-01-20 15:15         ` Alexis
  2015-01-21 23:05           ` Ingo Schwarze
  0 siblings, 1 reply; 15+ messages in thread
From: Alexis @ 2015-01-20 15:15 UTC (permalink / raw)
  To: Ingo Schwarze, Kristaps Dzonsons; +Cc: tech

Hi Ingo, hi Kristaps,
first off thank you very much for the insightful responses.

As for the fragmentation of OS X package managers
you might be "delighted" to hear that there's also Nixpkgs ;)
http://nixos.org/nixpkgs/

> > but it should be done right.  Doing a naive installation isn't enough.

I'm all up for it.

> I'd thoroughly hate that.  If you do that, i will remove all reference
> to your port from the homepage, and if need be, publish a statement
> that you deliberately patch vulnerabilities into software you are
> porting, urging people to not use your work.

Understood, I won't do that and patching software is gravely
frowned upon in Homebrew.

> > (By the way, did you plan on cron'ing makewhatis(8) or anything?)

I haven't up until now. I would need to find out how Mac OS X updates
its manpages, probably via a LaunchDaemon / LaunchAgent.

> Oh wait a minute.  I think i see a solution.  If we specifically
> allow mandoc to follow symlinks only into the homebrew tree, but
> nowhere else, that seems safe.  It's a bit tricky to avoid race
> conditions, but i think there is a secure way to implement it.  Is
> there are standardized place where homebrew installs its real files,
> and where nobody in their right mind would ever put any confidential
> data?  Maybe /Cellar?  Is that right?

Homebrew may be installed wherever a user desires (though /usr/local
is recommended) ranging from /opt/homebrew to $HOME/.brew. Because
of this Homebrew can also be installed and used without sudo
if the file permissions (e.g. homebrew group with write access)
are set up accordingly.

Is it possible to to add a configure.local variable so that the suite
of mdocml tools are compiled specifically for the user's setup, i.e.
make the suggested "/Cellar" customizable?

> > Essentially, the question is whether you want mandoc as a
> > constellation of tools (a man replacement) with security tools
> > or a developer tool.

I'd be okay with it, mandoc -Tlint has already been very helpful
for me!

> True, but the above might be a solution.  If we manage to support
> that, it would actually be a safe man(1) for homebrew, much safer
> than the traditional BSD or man-db implementations.

This sounds even better.


Best,
Alexis
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-17  1:07   ` Ingo Schwarze
  2015-01-17 20:10     ` Kristaps Dzonsons
@ 2015-01-20 15:19     ` Alexis
  2015-01-21 21:07       ` Ingo Schwarze
  1 sibling, 1 reply; 15+ messages in thread
From: Alexis @ 2015-01-20 15:19 UTC (permalink / raw)
  To: Ingo Schwarze; +Cc: tech

Hi Ingo
> For now, i have linked the pull request from
> 
>   http://mdocml.bsd.lv/ports.html
>   http://mdocml.bsd.lv/porthistory.html

Thanks, since I intend to update the Formula with the valuable input
from this list, how about linking to the latest version of it at:
https://github.com/afh/homebrew/blob/pull/mdocml/Library/Formula/mdocml.rb

> In case it gets merged to
> please tell me to update the link.

Will do.


Best,
Alexis
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-20 15:19     ` Alexis
@ 2015-01-21 21:07       ` Ingo Schwarze
  0 siblings, 0 replies; 15+ messages in thread
From: Ingo Schwarze @ 2015-01-21 21:07 UTC (permalink / raw)
  To: Alexis; +Cc: tech

Hi Alexis,

Alexis wrote on Tue, Jan 20, 2015 at 04:19:57PM +0100:
> Ingo Schwarze wrote:

>> For now, i have linked the pull request from
>> 
>>   http://mdocml.bsd.lv/ports.html
>>   http://mdocml.bsd.lv/porthistory.html

> Thanks, since I intend to update the Formula with the valuable input
> from this list, how about linking to the latest version of it at:
> https://github.com/afh/homebrew/blob/pull/mdocml/Library/Formula/mdocml.rb

That's what *is* linked from http://mdocml.bsd.lv/ports.html .

Only the porthistory page links to the original commit (and may
get additional links for important updates).

>> In case it gets merged to
>> please tell me to update the link.

> Will do.

Thank you,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-20 15:15         ` Alexis
@ 2015-01-21 23:05           ` Ingo Schwarze
  2015-01-22  0:21             ` Kristaps Dzonsons
  2015-01-22  7:26             ` Alexis
  0 siblings, 2 replies; 15+ messages in thread
From: Ingo Schwarze @ 2015-01-21 23:05 UTC (permalink / raw)
  To: Alexis; +Cc: Kristaps Dzonsons, tech

Hi Alexis,

Alexis wrote on Tue, Jan 20, 2015 at 04:15:01PM +0100:
> Ingo Schwarze wrote:

>> Oh wait a minute.  I think i see a solution.  If we specifically
>> allow mandoc to follow symlinks only into the homebrew tree, but
>> nowhere else, that seems safe.  It's a bit tricky to avoid race
>> conditions, but i think there is a secure way to implement it.

I just noticed there are more issues with race conditions,
so i shall have to address that separately at some point.

>> Is there are standardized place where homebrew installs its real
>> files, and where nobody in their right mind would ever put any
>> confidential data?  Maybe /Cellar?  Is that right?

> Homebrew may be installed wherever a user desires (though /usr/local
> is recommended) ranging from /opt/homebrew to $HOME/.brew. Because
> of this Homebrew can also be installed and used without sudo
> if the file permissions (e.g. homebrew group with write access)
> are set up accordingly.
> 
> Is it possible to to add a configure.local variable so that the suite
> of mdocml tools are compiled specifically for the user's setup, i.e.
> make the suggested "/Cellar" customizable?

Yes, that is easy and makes sense to me.

>> True, but the above might be a solution.  If we manage to support
>> that, it would actually be a safe man(1) for homebrew, much safer
>> than the traditional BSD or man-db implementations.

> This sounds even better.

See below for a patch i just committed to the HEAD of the mandoc CVS.

Kristaps, Alexis, are you able to test this on your Mac OS X boxes?

The intended behaviour is:

 1. If you compile without setting HOMEBREWDIR in configure.local
    or set it to a wrong value, makewhatis(8) is supposed to
    exlude homebrew-style linked manuals from mandoc.db(5)
    databases, like this:

     $ ./Bin/makewhatis -Dp Test           
    /co/mdocml/Test/: /usr/share/man/man1/cat.1: outside base directory

    In this case, apropos(1) is not supposed to find and man(1)
    is not supposed to show them, and the released version 1.13.2
    actually shouldn't.  In CVS HEAD, man(1) currently shows them,
    anyway, like this:

     $ man -M Test cat
    man: outdated mandoc.db lacks cat(1) entry,
         consider running  # makewhatis /co/mdocml/Test
    CAT(1)                General Commands Manual               CAT(1)
    NAME
         cat - concatenate and print files
    [...]

    I have to look into that...

 2. If you compile with HOMEBREWDIR set correctly in configure.local,
    makewhatis(8), apropos(1), and man(1) are supposed to work as
    expected.

Yours,
  Ingo


Log Message:
-----------
Support homebrew-style linking on Mac OS X.
Idea found together with Alexis Hildebrandt <surryhill at gmail dot com>.

Modified Files:
--------------
    mdocml:
        configure
        configure.local.example
        mandocdb.c

Revision Data
-------------
Index: mandocdb.c
===================================================================
RCS file: /home/cvs/mdocml/mdocml/mandocdb.c,v
retrieving revision 1.183
retrieving revision 1.184
diff -Lmandocdb.c -Lmandocdb.c -u -p -r1.183 -r1.184
--- mandocdb.c
+++ mandocdb.c
@@ -613,7 +613,11 @@ treescan(void)
 					say(path, "&realpath");
 				continue;
 			}
-			if (strstr(buf, basedir) != buf) {
+			if (strstr(buf, basedir) != buf
+#ifdef HOMEBREWDIR
+			    && strstr(buf, HOMEBREWDIR) != buf
+#endif
+			) {
 				if (warnings) say("",
 				    "%s: outside base directory", buf);
 				continue;
@@ -818,6 +822,10 @@ filescan(const char *file)
 		start = buf;
 	else if (strstr(buf, basedir) == buf)
 		start = buf + strlen(basedir);
+#ifdef HOMEBREWDIR
+	else if (strstr(buf, HOMEBREWDIR) == buf)
+		start = buf;
+#endif
 	else {
 		exitcode = (int)MANDOCLEVEL_BADARG;
 		say("", "%s: outside base directory", buf);
Index: configure.local.example
===================================================================
RCS file: /home/cvs/mdocml/mdocml/configure.local.example,v
retrieving revision 1.2
retrieving revision 1.3
diff -Lconfigure.local.example -Lconfigure.local.example -u -p -r1.2 -r1.3
--- configure.local.example
+++ configure.local.example
@@ -1,6 +1,6 @@
 # $Id$
 #
-# Copyright (c) 2014 Ingo Schwarze <schwarze@openbsd.org>
+# Copyright (c) 2014, 2015 Ingo Schwarze <schwarze@openbsd.org>
 #
 # Permission to use, copy, modify, and distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
@@ -152,6 +152,14 @@ BINM_APROPOS=mapropos		# default is "apr
 BINM_MAN=mman			# default is "man"
 BINM_WHATIS=mwhatis		# default is "whatis"
 BINM_MAKEWHATIS=mandocdb	# default is "makewhatis"
+
+# When using the "homebrew" package manager on Mac OS X, the actual
+# manuals are located in a so-called "cellar" and only symlinked
+# into the manual trees.  To allow mandoc to follow such symlinks,
+# you have to specify the physical location of the cellar as returned
+# by realpath(3), for example:
+
+HOMEBREWDIR=/Cellar
 
 # --- user settings related man.cgi ------------------------------------
 
Index: configure
===================================================================
RCS file: /home/cvs/mdocml/mdocml/configure,v
retrieving revision 1.17
retrieving revision 1.18
diff -Lconfigure -Lconfigure -u -p -r1.17 -r1.18
--- configure
+++ configure
@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# Copyright (c) 2014 Ingo Schwarze <schwarze@openbsd.org>
+# Copyright (c) 2014, 2015 Ingo Schwarze <schwarze@openbsd.org>
 #
 # Permission to use, copy, modify, and distribute this software for any
 # purpose with or without fee is hereby granted, provided that the above
@@ -70,6 +70,7 @@ INCLUDEDIR=
 LIBDIR=
 MANDIR=
 EXAMPLEDIR=
+HOMEBREWDIR=
 
 WWWPREFIX="/var/www"
 HTDOCDIR=
@@ -276,6 +277,7 @@ __HEREDOC__
 echo
 echo "#define VERSION \"${VERSION}\""
 [ -n "${OSNAME}" ] && echo "#define OSNAME \"${OSNAME}\""
+[ -n "${HOMEBREWDIR}" ] && echo "#define HOMEBREWDIR \"${HOMEBREWDIR}\""
 
 cat << __HEREDOC__
 #define HAVE_DIRENT_NAMLEN ${HAVE_DIRENT_NAMLEN}
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-21 23:05           ` Ingo Schwarze
@ 2015-01-22  0:21             ` Kristaps Dzonsons
  2015-01-22  0:35               ` Ingo Schwarze
  2015-01-22  7:26             ` Alexis
  1 sibling, 1 reply; 15+ messages in thread
From: Kristaps Dzonsons @ 2015-01-22  0:21 UTC (permalink / raw)
  To: Ingo Schwarze, Alexis; +Cc: tech

Ingo,

I think this is a bad idea: there shouldn't be conditionals in the code 
for every half-baked package manager out there, especially when they 
introduce security holes.

If there are other "linking" systems out there, then something like this 
might be useful.  But right now, homebrew is alone.

Alexis, you said that the homebrew folks don't like patching software. 
But there must be a facility to do so, no?  Shouldn't this patch be 
there, and not upstream?

Best,

Kristaps
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-22  0:21             ` Kristaps Dzonsons
@ 2015-01-22  0:35               ` Ingo Schwarze
  2015-01-22  7:32                 ` Alexis
  0 siblings, 1 reply; 15+ messages in thread
From: Ingo Schwarze @ 2015-01-22  0:35 UTC (permalink / raw)
  To: Kristaps Dzonsons; +Cc: Alexis, tech

Hi Kristaps,

Kristaps Dzonsons wrote on Thu, Jan 22, 2015 at 01:21:52AM +0100:

> I think this is a bad idea: there shouldn't be conditionals in the
> code for every half-baked package manager out there,

Right now, it doesn't seem execessive to me:  It's two places,
two lines each.  There is stuff that causes more pain, for
example the many lines "#if HAVE_SQLITE3" in main.c.

> especially when they introduce security holes.

Well, the way i did it does not cause security holes.

> If there are other "linking" systems out there, then something like
> this might be useful.  But right now, homebrew is alone.
> 
> Alexis, you said that the homebrew folks don't like patching
> software. But there must be a facility to do so, no?
> Shouldn't this patch be there, and not upstream?

I'm not quite sure that is better.  If we have the patch in our
tree, the risk that future code changes turn the patch into
something that actually *does* become a security risk seems
lower.

Also note that mdocml.bsd.lv *is* the portable version of mandoc,
so in the way, it is the right place to maintain such code - as
long as it doesn't grow out of hand and obscure the code.

You can be assured that i won't add such patches to the master
copy at cvs.openbsd.org...  ;-)

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-21 23:05           ` Ingo Schwarze
  2015-01-22  0:21             ` Kristaps Dzonsons
@ 2015-01-22  7:26             ` Alexis
  2015-01-23 22:05               ` Ingo Schwarze
  1 sibling, 1 reply; 15+ messages in thread
From: Alexis @ 2015-01-22  7:26 UTC (permalink / raw)
  To: Ingo Schwarze; +Cc: Kristaps Dzonsons, tech

Hi Ingo,
thanks for the changes!
I'll test as soon as Kristaps patch has made it into CVS.

In Hombrew what you named HOMEBREWDIR is named HOMEBREW_PREFIX,
it may or may not make sense to name the two alike.

Additionally I'd set the default of HOMEBREWDIR in
configure.local.example to either /usr/local (which is the default
installation directory of Homebrew as suggested on http://brew.sh) or
/opt/homebrew, but not /Cellar.  There is a Cellar sub-directory in the
Homebrew tree where all the installed software (they call them kegs)
reside and it might be confusing people.

It just occurred to me that you actually mean Cellar and want mandoc
to only use the files from the Cellar (due to the symlinks mentioned
in previous messages) in which case I'd rename HOMEBREWDIR to
HOMEBREW_CELLAR set its default to /usr/local/Cellar to make it more clear.


Best,
Alexis
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-22  0:35               ` Ingo Schwarze
@ 2015-01-22  7:32                 ` Alexis
  0 siblings, 0 replies; 15+ messages in thread
From: Alexis @ 2015-01-22  7:32 UTC (permalink / raw)
  To: Ingo Schwarze, Kristaps Dzonsons; +Cc: tech

Hi Ingo, hi Kristaps,
> > Alexis, you said that the homebrew folks don't like patching
> > software. But there must be a facility to do so, no?
> > Shouldn't this patch be there, and not upstream?

Yes, there is a facility in Homebrew to apply custom patches.
From my experience the maintainers want those patches to
be very specific to Homebrew and encourage changes to be reported
and made upstream.

> I'm not quite sure that is better.  If we have the patch in our
> tree, the risk that future code changes turn the patch into
> something that actually *does* become a security risk seems
> lower.
> 
> Also note that mdocml.bsd.lv *is* the portable version of mandoc,
> so in the way, it is the right place to maintain such code - as
> long as it doesn't grow out of hand and obscure the code.

I agree with Ingo here.


Best,
Alexis
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Allow configure variables to be set from environment
  2015-01-22  7:26             ` Alexis
@ 2015-01-23 22:05               ` Ingo Schwarze
  0 siblings, 0 replies; 15+ messages in thread
From: Ingo Schwarze @ 2015-01-23 22:05 UTC (permalink / raw)
  To: Alexis; +Cc: Kristaps Dzonsons, tech

Hi Alexis,

Alexis wrote on Thu, Jan 22, 2015 at 08:26:25AM +0100:

> thanks for the changes!
> I'll test as soon as Kristaps patch has made it into CVS.
> 
> In Hombrew what you named HOMEBREWDIR is named HOMEBREW_PREFIX,
> it may or may not make sense to name the two alike.
> 
> Additionally I'd set the default of HOMEBREWDIR in
> configure.local.example to either /usr/local (which is the default
> installation directory of Homebrew as suggested on http://brew.sh) or
> /opt/homebrew, but not /Cellar.  There is a Cellar sub-directory in the
> Homebrew tree where all the installed software (they call them kegs)
> reside and it might be confusing people.
> 
> It just occurred to me that you actually mean Cellar and want mandoc
> to only use the files from the Cellar (due to the symlinks mentioned
> in previous messages) in which case I'd rename HOMEBREWDIR to
> HOMEBREW_CELLAR set its default to /usr/local/Cellar to make it more clear.

Aha, that answers my original question what the usual place is
where, unless the user decides otherwise, homebrew installs
software: /usr/local/Cellar.

So i have applied the following patch.

I don't like calling the variable HOMEBREW_CELLAR.  Except PREFIX,
which is a widely used variable called thus in many contexts (even
in homebrew, apparently), all the directory variables in the mandoc
configuration and build system end in "*DIR", don't contain
underscores, and HOMEBREWCELLARDIR would be just too long and ugly.

Yours,
  Ingo


Log Message:
-----------
improve homebrew cellar config example

Modified Files:
--------------
    mdocml:
        configure.local.example

Revision Data
-------------
Index: configure.local.example
===================================================================
RCS file: /home/cvs/mdocml/mdocml/configure.local.example,v
retrieving revision 1.3
retrieving revision 1.4
diff -Lconfigure.local.example -Lconfigure.local.example -u -p -r1.3 -r1.4
--- configure.local.example
+++ configure.local.example
@@ -159,7 +159,8 @@ BINM_MAKEWHATIS=mandocdb	# default is "m
 # you have to specify the physical location of the cellar as returned
 # by realpath(3), for example:
 
-HOMEBREWDIR=/Cellar
+PREFIX="/usr/local"
+HOMEBREWDIR="${PREFIX}/Cellar"
 
 # --- user settings related man.cgi ------------------------------------
 
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2015-01-23 22:05 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <sfid-H20150116-225859-+021.89-1@spamfilter.osbf.lua>
2015-01-16 21:58 ` Allow configure variables to be set from environment Alexis
2015-01-16 23:32   ` Thomas Klausner
2015-01-17  1:31     ` Ingo Schwarze
2015-01-17  1:07   ` Ingo Schwarze
2015-01-17 20:10     ` Kristaps Dzonsons
2015-01-18  3:33       ` Ingo Schwarze
2015-01-20 15:15         ` Alexis
2015-01-21 23:05           ` Ingo Schwarze
2015-01-22  0:21             ` Kristaps Dzonsons
2015-01-22  0:35               ` Ingo Schwarze
2015-01-22  7:32                 ` Alexis
2015-01-22  7:26             ` Alexis
2015-01-23 22:05               ` Ingo Schwarze
2015-01-20 15:19     ` Alexis
2015-01-21 21:07       ` Ingo Schwarze

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).