Re: update lang/fennel; move man pages to a -docs subpackage

2023-09-19 Thread Ingo Schwarze
Hi Omar,

Omar Polo wrote on Tue, Sep 19, 2023 at 02:30:08PM +0200:

> I have to note that one could end up installing only the -docs
> package, is it a concern?

If a user explicitely says "pkg_add fennel-docs" without
saying "pkg_add fennel", sure, they only get the documentation
installed.  But that's what they asked for, so i don't see a
problem there.  Occasionally, it might even be useful, for
example when a user on a very slow network connection wants
to look at the documentation before deciding whether they
really want to download the code (and the other dependencies 
like lua).  Maybe not the usual case - when you want to study
documentation, you usually also want to play around a bit
with the program - but clearly not harmful.

It certainly won't be the only package containing documentation
only and no code.  Consider, for example, books/man-pages-posix.

Yours,
  Ingo



Re: update lang/fennel; move man pages to a -docs subpackage

2023-09-19 Thread Omar Polo
On 2023/09/19 12:38:52 +0100, Stuart Henderson  wrote:
> On 2023/09/19 11:32, Ingo Schwarze wrote:
> > Hi Omar,
> > 
> > Omar Polo wrote on Tue, Sep 19, 2023 at 10:10:44AM +0200:
> > 
> > > However, I disliked to ship the same set of man pages four times, so
> > > here's an attempt to move them to a -docs subpackage.  (thanks sthen@
> > > for pointing me at www/squid)
> > 
> > I wouldn't consider saving the diskspace for three manual pages the
> > main benefit, even though that hardly hurts, either.  It seems more
> > important that your approach of making a subpackage prevents apropos(1)
> > from listing multiple pages and making the user wonder whether they
> > differ, possibly wasting their time running diff(1).
> > 
> > This is even likely to become worse in the near future when man(1)
> > starts warning that there are multiple manual pages of the same name
> > in the same section.
> > 
> > However, *if* you expect that the pages are likely to actually
> > become different in the future, that might be a reason against
> > making this subpackage.  Then again, if that happens, it would
> > also be an option to merge them back in after it happens.
> 
> They won't; the different flavours are merely building with different
> versions of lua, the manuals are unaffected.

Currently they don't change and I don't expect them to change in the
future.

> > > Note that RUN_DEPENDS-docs is needed otherwise (via lua.port.mk and
> > > global RUN_DEPENDS) it ends up depending on lang/lua,${FLAVOR} and
> > > that will break subsequent build (the plist register the deps on one
> > > flavor, when building the next one the plist would differ)
> > 
> > Again, i don't think these technical considerations are the only
> > reason for RUN_DEPENDS-docs.  I general, i stongly feel that if
> > you say "pkg_add food", that should absolutely install all the
> > documentation for the "foo" daemon.  I mean, how is the user
> > supposed to use it if there is no documentation?  We want sane
> > defaults, and installing software without documentation is not
> > exactly sane.  Why should we send the user on a wild goose chase
> > to search for a "foo" documentation package after they alraedy
> > said they want food?
> > 
> > I certainly don't want to emulate the bad habit of some Linux
> > distros to not install documentation unless the user goes an extra
> > mile specifically asking for it.

Completely agree.

> Explicitly setting RUN_DEPENDS-docs to  makes sense,
> but I think we should also have "RUN_DEPENDS-main += lang/fennel,-docs".

There is already a RUN_DEPENDS-main += lang/fennel,-docs, so nevermind
which flavor(s) you install the -docs subpackage will always be
installed as dependency.

It was at the top together with the FULLPKGNAME/PATH bits, so easy to
miss.  I've moved it in a more usual position near the end.

I have to note that one could end up installing only the -docs
package, is it a concern?

> Otherwise the ports aspects look correct to me.
> 
> > > However, I'm not sure I'm overthinking it and just rename the three
> > > new manpages to fennel-${V}-XYZ instead of doing a subpackage would be
> > > preferred.
> > 
> > I did not audit this ports-wise, but i do like your general idea.
> > It doesn't feel like overengineering to me, there appear to be actual
> > benefits from the user perspective.
> 
> Agreed.
> 
> > > +SITES =  https://git.sr.ht/~technomancy/fennel/archive/
> 
> btw, I think this could probably change to DIST_TUPLES if wanted.

right, while we're here it also further semplifies the makefile.

Ingo, Sthen, thanks!


Index: Makefile
===
RCS file: /home/cvs/ports/lang/fennel/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile26 Dec 2022 11:05:59 -  1.2
+++ Makefile19 Sep 2023 12:17:07 -
@@ -1,8 +1,14 @@
-COMMENT =  Lisp dialect that runs on Lua ${MODLUA_VERSION}
+COMMENT-main = Lisp dialect that runs on Lua ${MODLUA_VERSION}
+COMMENT-docs = Documentation for fennel
 
-V =1.2.1
-PKGNAME =  fennel-$V
-FULLPKGNAME =  fennel-${FLAVOR}-${V}
+V =1.3.1
+DIST_TUPLE =   srht technomancy fennel $V .
+FULLPKGPATH-main = lang/fennel,-main,${FLAVOR}
+FULLPKGNAME-main = fennel-${FLAVOR}-${V}
+
+# -docs isn't flavoured, so overwrite its default name/path
+FULLPKGNAME-docs = fennel-docs-$V
+FULLPKGPATH-docs = ${PKGPATH},-docs
 
 CATEGORIES =   lang
 
@@ -13,9 +19,7 @@ MAINTAINER =  Omar Polo 
 # MIT
 PERMIT_PACKAGE = Yes
 
-MASTER_SITES = https://git.sr.ht/~technomancy/fennel/archive/
-
-DISTFILES =fennel-{}$V${EXTRACT_SUFX}
+MULTI_PACKAGES = -main -docs
 
 MODULES =  lang/lua
 
@@ -29,13 +33,14 @@ ALL_TARGET =build
 MAKE_FLAGS +=  LUA=${MODLUA_BIN} \
LUA_VERSION=${MODLUA_VERSION} \
LUA_LIB_DIR=${MODLUA_LIBDIR}
-FAKE_FLAGS +=  PREFIX=${TRUEPREFIX}
+FAKE_FLAGS +=  PREFIX=${TRUEPREFIX} \
+   

Re: update lang/fennel; move man pages to a -docs subpackage

2023-09-19 Thread Stuart Henderson
On 2023/09/19 11:32, Ingo Schwarze wrote:
> Hi Omar,
> 
> Omar Polo wrote on Tue, Sep 19, 2023 at 10:10:44AM +0200:
> 
> > The update itself is straightforward and all tests are passing.
> > However, upstream added three more man pages (for a total of four now)
> > which would get shipped in all of four fennel flavors (lua5[1-3]).
> > 
> > Now, this is practice works, i.e. even if you have installed all the
> > flavors `man fennel-api' works and since all the manpages are
> > identical it's not really important if mandoc chooses fennel-5.1-api
> > or fennel-5.4-api.
> > 
> > However, I disliked to ship the same set of man pages four times, so
> > here's an attempt to move them to a -docs subpackage.  (thanks sthen@
> > for pointing me at www/squid)
> 
> I wouldn't consider saving the diskspace for three manual pages the
> main benefit, even though that hardly hurts, either.  It seems more
> important that your approach of making a subpackage prevents apropos(1)
> from listing multiple pages and making the user wonder whether they
> differ, possibly wasting their time running diff(1).
> 
> This is even likely to become worse in the near future when man(1)
> starts warning that there are multiple manual pages of the same name
> in the same section.
> 
> However, *if* you expect that the pages are likely to actually
> become different in the future, that might be a reason against
> making this subpackage.  Then again, if that happens, it would
> also be an option to merge them back in after it happens.

They won't; the different flavours are merely building with different
versions of lua, the manuals are unaffected.

> > Note that RUN_DEPENDS-docs is needed otherwise (via lua.port.mk and
> > global RUN_DEPENDS) it ends up depending on lang/lua,${FLAVOR} and
> > that will break subsequent build (the plist register the deps on one
> > flavor, when building the next one the plist would differ)
> 
> Again, i don't think these technical considerations are the only
> reason for RUN_DEPENDS-docs.  I general, i stongly feel that if
> you say "pkg_add food", that should absolutely install all the
> documentation for the "foo" daemon.  I mean, how is the user
> supposed to use it if there is no documentation?  We want sane
> defaults, and installing software without documentation is not
> exactly sane.  Why should we send the user on a wild goose chase
> to search for a "foo" documentation package after they alraedy
> said they want food?
> 
> I certainly don't want to emulate the bad habit of some Linux
> distros to not install documentation unless the user goes an extra
> mile specifically asking for it.

Explicitly setting RUN_DEPENDS-docs to  makes sense,
but I think we should also have "RUN_DEPENDS-main += lang/fennel,-docs".

Otherwise the ports aspects look correct to me.

> > However, I'm not sure I'm overthinking it and just rename the three
> > new manpages to fennel-${V}-XYZ instead of doing a subpackage would be
> > preferred.
> 
> I did not audit this ports-wise, but i do like your general idea.
> It doesn't feel like overengineering to me, there appear to be actual
> benefits from the user perspective.

Agreed.

> > +SITES =  https://git.sr.ht/~technomancy/fennel/archive/

btw, I think this could probably change to DIST_TUPLES if wanted.



Re: update lang/fennel; move man pages to a -docs subpackage

2023-09-19 Thread Ingo Schwarze
Hi Omar,

Omar Polo wrote on Tue, Sep 19, 2023 at 10:10:44AM +0200:

> The update itself is straightforward and all tests are passing.
> However, upstream added three more man pages (for a total of four now)
> which would get shipped in all of four fennel flavors (lua5[1-3]).
> 
> Now, this is practice works, i.e. even if you have installed all the
> flavors `man fennel-api' works and since all the manpages are
> identical it's not really important if mandoc chooses fennel-5.1-api
> or fennel-5.4-api.
> 
> However, I disliked to ship the same set of man pages four times, so
> here's an attempt to move them to a -docs subpackage.  (thanks sthen@
> for pointing me at www/squid)

I wouldn't consider saving the diskspace for three manual pages the
main benefit, even though that hardly hurts, either.  It seems more
important that your approach of making a subpackage prevents apropos(1)
from listing multiple pages and making the user wonder whether they
differ, possibly wasting their time running diff(1).

This is even likely to become worse in the near future when man(1)
starts warning that there are multiple manual pages of the same name
in the same section.

However, *if* you expect that the pages are likely to actually
become different in the future, that might be a reason against
making this subpackage.  Then again, if that happens, it would
also be an option to merge them back in after it happens.

> Note that RUN_DEPENDS-docs is needed otherwise (via lua.port.mk and
> global RUN_DEPENDS) it ends up depending on lang/lua,${FLAVOR} and
> that will break subsequent build (the plist register the deps on one
> flavor, when building the next one the plist would differ)

Again, i don't think these technical considerations are the only
reason for RUN_DEPENDS-docs.  I general, i stongly feel that if
you say "pkg_add food", that should absolutely install all the
documentation for the "foo" daemon.  I mean, how is the user
supposed to use it if there is no documentation?  We want sane
defaults, and installing software without documentation is not
exactly sane.  Why should we send the user on a wild goose chase
to search for a "foo" documentation package after they alraedy
said they want food?

I certainly don't want to emulate the bad habit of some Linux
distros to not install documentation unless the user goes an extra
mile specifically asking for it.

> However, I'm not sure I'm overthinking it and just rename the three
> new manpages to fennel-${V}-XYZ instead of doing a subpackage would be
> preferred.

I did not audit this ports-wise, but i do like your general idea.
It doesn't feel like overengineering to me, there appear to be actual
benefits from the user perspective.

Yours,
  Ingo



update lang/fennel; move man pages to a -docs subpackage

2023-09-19 Thread Omar Polo
The update itself is straightforward and all tests are passing.
However, upstream added three more man pages (for a total of four now)
which would get shipped in all of four fennel flavors (lua5[1-3]).

Now, this is practice works, i.e. even if you have installed all the
flavors `man fennel-api' works and since all the manpages are
identical it's not really important if mandoc chooses fennel-5.1-api
or fennel-5.4-api.

However, I disliked to ship the same set of man pages four times, so
here's an attempt to move them to a -docs subpackage.  (thanks sthen@
for pointing me at www/squid)

Note that RUN_DEPENDS-docs is needed otherwise (via lua.port.mk and
global RUN_DEPENDS) it ends up depending on lang/lua,${FLAVOR} and
that will break subsequent build (the plist register the deps on one
flavor, when building the next one the plist would differ)

However, I'm not sure I'm overthinking it and just rename the three
new manpages to fennel-${V}-XYZ instead of doing a subpackage would be
preferred.


Index: Makefile
===
RCS file: /home/cvs/ports/lang/fennel/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile26 Dec 2022 11:05:59 -  1.2
+++ Makefile18 Sep 2023 15:52:07 -
@@ -1,8 +1,16 @@
-COMMENT =  Lisp dialect that runs on Lua ${MODLUA_VERSION}
+COMMENT-main = Lisp dialect that runs on Lua ${MODLUA_VERSION}
+COMMENT-docs = Documentation for fennel
 
-V =1.2.1
+V =1.3.1
 PKGNAME =  fennel-$V
-FULLPKGNAME =  fennel-${FLAVOR}-${V}
+FULLPKGPATH-main = lang/fennel,-main,${FLAVOR}
+FULLPKGNAME-main = fennel-${FLAVOR}-${V}
+
+# -docs isn't flavoured, so overwrite its default name/path
+FULLPKGNAME-docs = fennel-docs-$V
+FULLPKGPATH-docs = ${PKGPATH},-docs
+RUN_DEPENDS-main+= lang/fennel,-docs
+RUN_DEPENDS-docs =
 
 CATEGORIES =   lang
 
@@ -13,7 +21,9 @@ MAINTAINER =  Omar Polo 
 # MIT
 PERMIT_PACKAGE = Yes
 
-MASTER_SITES = https://git.sr.ht/~technomancy/fennel/archive/
+MULTI_PACKAGES = -main -docs
+
+SITES =https://git.sr.ht/~technomancy/fennel/archive/
 
 DISTFILES =fennel-{}$V${EXTRACT_SUFX}
 
@@ -29,13 +39,13 @@ ALL_TARGET =build
 MAKE_FLAGS +=  LUA=${MODLUA_BIN} \
LUA_VERSION=${MODLUA_VERSION} \
LUA_LIB_DIR=${MODLUA_LIBDIR}
-FAKE_FLAGS +=  PREFIX=${TRUEPREFIX}
+FAKE_FLAGS +=  PREFIX=${TRUEPREFIX} \
+   MAN_DIR=${PREFIX}
 
 WRKDIST =  ${WRKDIR}/${PKGNAME}
 
 post-install:
chmod +x ${PREFIX}/bin/fennel
cd ${PREFIX}/bin && mv fennel fennel-${MODLUA_VERSION}
-   cd ${PREFIX}/man/man1 && mv fennel.1 fennel-${MODLUA_VERSION}.1
 
 .include 
Index: distinfo
===
RCS file: /home/cvs/ports/lang/fennel/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo24 Dec 2022 08:57:07 -  1.1.1.1
+++ distinfo18 Sep 2023 11:20:49 -
@@ -1,2 +1,2 @@
-SHA256 (fennel-1.2.1.tar.gz) = ZlSq23ZZu/iNOHkZA5JXPhrjkIfqr1CE6V9F246CrVE=
-SIZE (fennel-1.2.1.tar.gz) = 271590
+SHA256 (fennel-1.3.1.tar.gz) = gz2Qt+me3Uh0A/Uf38PLsmO/lltyqRS7u7AVbGEy1GU=
+SIZE (fennel-1.3.1.tar.gz) = 293564
Index: pkg/DESCR
===
RCS file: pkg/DESCR
diff -N pkg/DESCR
--- pkg/DESCR   24 Dec 2022 08:57:07 -  1.1.1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-Fennel is a programming language that brings together the speed,
-simplicity, and reach of Lua with the flexibility of a lisp syntax and
-macro system.
-
- - Full Lua compatibility: Easily call any Lua function or library from
-   Fennel and vice-versa.
-
- - Zero overhead: Compiled code should be just as efficient as
-   hand-written Lua.
-
- - Compile-time macros: Ship compiled code with no runtime dependency on
-   Fennel.
-
- - Embeddable: Fennel is a one-file library as well as an executable.
-   Embed it in other programs to support runtime extensibility and
-   interactive development.
Index: pkg/DESCR-docs
===
RCS file: pkg/DESCR-docs
diff -N pkg/DESCR-docs
--- /dev/null   1 Jan 1970 00:00:00 -
+++ pkg/DESCR-docs  19 Sep 2023 08:09:09 -
@@ -0,0 +1 @@
+Manual pages for fennel.
Index: pkg/DESCR-main
===
RCS file: pkg/DESCR-main
diff -N pkg/DESCR-main
--- /dev/null   1 Jan 1970 00:00:00 -
+++ pkg/DESCR-main  24 Dec 2022 08:57:07 -
@@ -0,0 +1,16 @@
+Fennel is a programming language that brings together the speed,
+simplicity, and reach of Lua with the flexibility of a lisp syntax and
+macro system.
+
+ - Full Lua compatibility: Easily call any Lua function or library from
+   Fennel and vice-versa.
+
+ - Zero overhead: Compiled code should be just as efficient as
+   hand-written Lua.
+
+ - Compile-time macros: Ship compiled code with