Re: [update] devel/p5-File-ChangeNotify 0.28 -> 0.31
On Sat, May 04, 2019 at 10:58:04AM +0200, Charlene Wendling wrote: > Hi ports, > > Here is an update for File::ChangeNotify. > > What's new upstream [0]: > > - Don't use Class::Load anymore > - New feature: track path attribute changes (permissions, > ownership), providing old vs new attributes and contents > in modify events. As it's resource-intensive, it's not > enabled by default. > > Port-wise it's a simple update with a dependency overhaul. > > Testing: > > - 'make test' passes > - There are 6 consumers, and i've found no new failures due to that > update [1]. > > Comments and feedback are welcome. OK afresh1@ > Charlène. > > > [0] https://metacpan.org/source/DROLSKY/File-ChangeNotify-0.31/Changes > [1] http://0x0.st/zcRi.tgz > > > Index: Makefile > === > RCS file: /cvs/ports/devel/p5-File-ChangeNotify/Makefile,v > retrieving revision 1.12 > diff -u -p -u -p -r1.12 Makefile > --- Makefile 29 Apr 2018 13:03:51 - 1.12 > +++ Makefile 4 May 2019 08:45:55 - > @@ -2,7 +2,7 @@ > > COMMENT =watch for changes to files, cross-platform style > > -DISTNAME = File-ChangeNotify-0.28 > +DISTNAME = File-ChangeNotify-0.31 > > CATEGORIES = devel > > @@ -11,16 +11,15 @@ PERMIT_PACKAGE_CDROM =Yes > > MODULES =cpan > > -RUN_DEPENDS =devel/p5-Class-Load \ > - devel/p5-Module-Pluggable \ > +RUN_DEPENDS =devel/p5-Module-Pluggable \ > devel/p5-Module-Runtime \ > - devel/p5-Moo \ > + devel/p5-Moo>=1.006 \ > devel/p5-Type-Tiny \ > devel/p5-namespace-autoclean > > -TEST_DEPENDS = devel/p5-Test-Exception \ > - devel/p5-Test-Requires \ > - devel/p5-Test-Without-Module > +TEST_DEPENDS = devel/p5-Test-Requires \ > + devel/p5-Test-Without-Module \ > + devel/p5-Test2-Suite > > PKG_ARCH = * > > Index: distinfo > === > RCS file: /cvs/ports/devel/p5-File-ChangeNotify/distinfo,v > retrieving revision 1.7 > diff -u -p -u -p -r1.7 distinfo > --- distinfo 29 Apr 2018 13:03:51 - 1.7 > +++ distinfo 4 May 2019 08:45:55 - > @@ -1,2 +1,2 @@ > -SHA256 (File-ChangeNotify-0.28.tar.gz) = > 4A/oCdSBExoI3KJuhRzw/86Nnp0D1YxY8VqmLiiqLwU= > -SIZE (File-ChangeNotify-0.28.tar.gz) = 35676 > +SHA256 (File-ChangeNotify-0.31.tar.gz) = > GSvbHOdiZsamlKjpYtA5463uuCm2rB4j9QV/K1Bjkr0= > +SIZE (File-ChangeNotify-0.31.tar.gz) = 41447 > -- andrew - http://afresh1.com People who invent random theories which only defend the vendor must have been beaten as children. Beaten with sticks. At least, that's my theory. -- Theo De Raadt
Re: UPDATE: devel/p5-File-ChangeNotify
Mikolaj Kucharski writes:
> So, File::ChangeNotify doesn't handle resource limits gracefuly,
> yeah[ref#2]? If that is true, your changes make sense for me.
Yes, exactly. The KQueue-based watcher class doesn't fall back to
polling if it runs out of file descriptors.
I've attached an updated diff. This version of the port creates a
p5-File-ChangeNotify-Watcher-KQueue package in addition to the main
package. The main package provides the slow default watcher that doesn't
require any further configuration. As soon as the sub package is
installed the KQueue-based watcher becomes the default.
Index: Makefile
===
RCS file: /cvs/ports/devel/p5-File-ChangeNotify/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- Makefile3 Dec 2010 11:44:31 - 1.5
+++ Makefile1 Jan 2011 17:25:18 -
@@ -1,25 +1,34 @@
# $OpenBSD: Makefile,v 1.5 2010/12/03 11:44:31 ajacoutot Exp $
-COMMENT= watch for changes to files, cross-platform style
+COMMENT-main= watch for changes to files, cross-platform style
+COMMENT-kqueue=watch for changes to files (KQueue-based)
MODULES= cpan
-DISTNAME= File-ChangeNotify-0.13
-REVISION= 0
+DISTNAME= File-ChangeNotify-0.19
+PKGNAME-main= p5-File-ChangeNotify-0.19
+PKGNAME-kqueue=p5-File-ChangeNotify-Watcher-KQueue-0.19
CATEGORIES=devel
-# Perl
+# Artistic 2.0
PERMIT_PACKAGE_CDROM = Yes
PERMIT_PACKAGE_FTP = Yes
PERMIT_DISTFILES_CDROM = Yes
PERMIT_DISTFILES_FTP = Yes
+MULTI_PACKAGES = -main -kqueue
+
CONFIGURE_STYLE = modbuild
-USE_GROFF =Yes
-RUN_DEPENDS = devel/p5-Class-MOP \
- devel/p5-Moose \
- devel/p5-MooseX-Params-Validate \
- devel/p5-MooseX-SemiAffordanceAccessor
+BUILD_DEPENDS =${RUN_DEPENDS-main} \
+ devel/p5-IO-KQueue
+RUN_DEPENDS-main = devel/p5-Class-MOP \
+ devel/p5-Moose \
+ devel/p5-MooseX-Params-Validate \
+ devel/p5-MooseX-SemiAffordanceAccessor \
+ devel/p5-namespace-autoclean
+RUN_DEPENDS-kqueue = devel/p5-File-ChangeNotify \
+ devel/p5-IO-KQueue
+REGRESS_DEPENDS = devel/p5-Test-Exception
MAKE_ENV +=TEST_POD=1 IS_MAINTAINER=1
Index: distinfo
===
RCS file: /cvs/ports/devel/p5-File-ChangeNotify/distinfo,v
retrieving revision 1.2
diff -u -r1.2 distinfo
--- distinfo3 Jul 2010 03:41:42 - 1.2
+++ distinfo1 Jan 2011 17:25:18 -
@@ -1,5 +1,5 @@
-MD5 (File-ChangeNotify-0.13.tar.gz) = eR70uZegW1BwTiwo+Ph4oA==
-RMD160 (File-ChangeNotify-0.13.tar.gz) = Jltiid+UQa63uHcm5mBS2KnQ69s=
-SHA1 (File-ChangeNotify-0.13.tar.gz) = WcEiFJwmsqrqCjYp2xNnbAlSbqM=
-SHA256 (File-ChangeNotify-0.13.tar.gz) =
yHAoVdthRnb9v2P9raOA6tj2FAE11Y1TkUQuDYmpaig=
-SIZE (File-ChangeNotify-0.13.tar.gz) = 18155
+MD5 (File-ChangeNotify-0.19.tar.gz) = VQwjU6nvRVIDu8AC7DGr+A==
+RMD160 (File-ChangeNotify-0.19.tar.gz) = AR00UgFZUSdOzuYz8k9v6hycoho=
+SHA1 (File-ChangeNotify-0.19.tar.gz) = kHUhoX7Qh7eHUQZHMhP2WNo+WaE=
+SHA256 (File-ChangeNotify-0.19.tar.gz) =
8UfmQPMm0uG3XrKZ+1LXcDXbEE+evsc71IuEhBOXAdA=
+SIZE (File-ChangeNotify-0.19.tar.gz) = 19908
Index: patches/patch-lib_File_ChangeNotify_Watcher_KQueue_pm
===
RCS file: patches/patch-lib_File_ChangeNotify_Watcher_KQueue_pm
diff -N patches/patch-lib_File_ChangeNotify_Watcher_KQueue_pm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-lib_File_ChangeNotify_Watcher_KQueue_pm 1 Jan 2011
17:25:18 -
@@ -0,0 +1,23 @@
+$OpenBSD$
+--- lib/File/ChangeNotify/Watcher/KQueue.pm.orig Sun Oct 17 22:00:14 2010
lib/File/ChangeNotify/Watcher/KQueue.pmSat Jan 1 10:21:31 2011
+@@ -184,7 +184,7 @@ sub _watch_file {
+
+ # Don't panic if we can't open a file
+ open my $fh, '<', $file or warn "Can't open '$file': $!";
+-return unless $fh;
++return unless $fh && defined fileno($fh);
+
+ # Store this filehandle (this will automatically nuke any existing events
+ # assigned to the file)
+@@ -229,6 +229,10 @@ On FreeBSD, you can check (and alter) your system's se
+ necessary. The important keys are: C and
+ C. You can see how many files your system current has
+ open with C.
++
++On OpenBSD, the C keys are C and C.
++Per-process limits are set in F. See L and
++L for details.
+
+ =head1 SUPPORT
+
Index: pkg/DESCR
===
RCS file: pkg/DESCR
diff -N pkg/DESCR
--- pkg/DESCR 27 Oct 2009 00:31:20 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,2 +0,0 @@
-Watch for changes to files, cross-platform style via an API for creating
-a File::ChangeNotify::Watcher subclass that will work on your platform.
Index: pkg/DESCR-kq
Re: UPDATE: devel/p5-File-ChangeNotify
On Sat, Jan 01, 2011 at 03:34:27PM +0100, Andreas Vögele wrote: > Mikolaj Kucharski writes: > > On Sat, Jan 01, 2011 at 01:23:12PM +0100, Andreas Vögele wrote: > >> It seems that the port so far didn't take into account that the > >> p5-IO-KQueue package could be installed on the system. Since the > >> KQueue-based file watcher quickly exceeds the maximum number of > >> open files in a default OpenBSD installation, I changed > >> ChangeNotify.pm to prefer the Default watcher even if IO::KQueue is > >> available. I think this is more reasonable than to ask the users to > >> raise their openfiles and maxfiles limits from 128 and 7030 to much > >> higher values. > > > > Ok. What about users, who altered their system already, and have > > raised kern.maxfiles and openfiles-cur in login.conf(5) for example, > > for gam_server (see gamin package). > > > > Not that I am using ChangeNotify.pm, but what is default watcher in > > that module? > > The default is the Default watcher unless you have happened to install That's the name of default watcher, the `Default', yeah? Confusing.. > the p5-IO-KQueue package, which the current p5-File-ChangeNotify package > does NOT depend on. If anybody uses p5-File-ChangeNotify _with_ > p5-IO-KQueue _and_ has raised the resource limits that person should > have complained a long time ago about the missing dependency on > p5-IO-KQueue. Because IO::KQueue to work reliably makes the user to modify login class capabilities and system resources personally I think lack of dependency in p5-File-ChangeNotify on p5-IO-KQueue is good idea. I don't have anything against what is currently in p5-File-ChangeNotify port in terms of dependencies on IO::KQueue[ref#1]. > > Which watcher is more efficient? Does your change (to not use > > IO::KQueue as default watcher) help the user of ChangeNotify.pm in > > any way? > > In my opinion robustness is more important than efficiency. The ports > and packages are supposed to make life simple for the users. If the > KQueue-based watcher becomes the default, most users who install > p5-File-ChangeNotify - very likely because of a dependency - will have > to raise their resource limits. The default for the openfiles resource > limit is 128, which means that the KQueue-based watcher will fail on any > directory that contains more than 127 files. The Default watcher on the > other hand is slower but can handle large directories without any > modification to the system's configuration. What means "the KQueue-based watcher will fail" in above context? Will IO::KQueue croak/die if it hit resource limit and File::ChangeNotify currently doesn't handle when one watcher fails to switch to another one[ref#2]? > > As wrote above, I'm not using module in subject, but I have concerns > > for changing defaults.. I'm asking as I feel I'm missing something to > > understand reasoning. > > I doubt that the defaults are changed for anybody. On the contrary, so > far the port doesn't depend on p5-IO-KQueue, which suggests that whoever > created this port didn't consider the KQueue-based watcher. Actually, if > the p5-IO-KQueue package is installed the regression tests of the > current port fail because of a bug in KQueue.pm. My guess is that the > port was merely created to satisfy dependencies. As wrote above[ref#1], that makes sense for me to not force user to use IO::KQueue (but use it when is makes sense -- when IO::KQueue is installed and properly configured -- read sysctl.conf and login.conf limits bumped). > Also, if p5-IO-KQueue is pulled in by some other package, the current > p5-File-ChangeNotify package might suddenly start to fail because the > installation of p5-IO-KQueue changes the default from the Default > watcher to the KQueue watcher. This is not what users expect. > > Furthermore, it's not possible to automatically decide at runtime > whether to use the Default or the KQueue watcher. When the watcher is > instantiated the size of the directory is not known. Also, directories > might grow during runtime. Using the KQueue-based watcher is dangerous > unless you know for sure that the size of the watched directories will > never exceed your resource limits. > > A hybrid watcher that tries to use KQueue and falls back to the Default > mechanism if a threshold of available file descriptors is reached could > make sense though. But my goal is just to get this port updated so that > eventually Moose can be updated. So, File::ChangeNotify doesn't handle resource limits gracefuly, yeah[ref#2]? If that is true, your changes make sense for me. -- best regards q#
Re: UPDATE: devel/p5-File-ChangeNotify
Andreas Vögele writes: > Mikolaj Kucharski writes: >> On Sat, Jan 01, 2011 at 01:23:12PM +0100, Andreas Vögele wrote: >>> It seems that the port so far didn't take into account that the >>> p5-IO-KQueue package could be installed on the system. Since the >>> KQueue-based file watcher quickly exceeds the maximum number of >>> open files in a default OpenBSD installation, I changed >>> ChangeNotify.pm to prefer the Default watcher even if IO::KQueue is >>> available. I think this is more reasonable than to ask the users to >>> raise their openfiles and maxfiles limits from 128 and 7030 to much >>> higher values. >> >> Ok. What about users, who altered their system already, and have >> raised kern.maxfiles and openfiles-cur in login.conf(5) for example, >> for gam_server (see gamin package). >> >> Not that I am using ChangeNotify.pm, but what is default watcher in >> that module? > > The default is the Default watcher unless you have happened to install > the p5-IO-KQueue package, which the current p5-File-ChangeNotify package > does NOT depend on. [...] I will put the KQueue-based stuff into a sub package. That way the Default watcher stays the default until the optional sub package is installed, which will switch the default to the KQueue-based watcher.
Re: UPDATE: devel/p5-File-ChangeNotify
Mikolaj Kucharski writes: > On Sat, Jan 01, 2011 at 01:23:12PM +0100, Andreas Vögele wrote: >> It seems that the port so far didn't take into account that the >> p5-IO-KQueue package could be installed on the system. Since the >> KQueue-based file watcher quickly exceeds the maximum number of >> open files in a default OpenBSD installation, I changed >> ChangeNotify.pm to prefer the Default watcher even if IO::KQueue is >> available. I think this is more reasonable than to ask the users to >> raise their openfiles and maxfiles limits from 128 and 7030 to much >> higher values. > > Ok. What about users, who altered their system already, and have > raised kern.maxfiles and openfiles-cur in login.conf(5) for example, > for gam_server (see gamin package). > > Not that I am using ChangeNotify.pm, but what is default watcher in > that module? The default is the Default watcher unless you have happened to install the p5-IO-KQueue package, which the current p5-File-ChangeNotify package does NOT depend on. If anybody uses p5-File-ChangeNotify _with_ p5-IO-KQueue _and_ has raised the resource limits that person should have complained a long time ago about the missing dependency on p5-IO-KQueue. > Which watcher is more efficient? Does your change (to not use > IO::KQueue as default watcher) help the user of ChangeNotify.pm in > any way? In my opinion robustness is more important than efficiency. The ports and packages are supposed to make life simple for the users. If the KQueue-based watcher becomes the default, most users who install p5-File-ChangeNotify - very likely because of a dependency - will have to raise their resource limits. The default for the openfiles resource limit is 128, which means that the KQueue-based watcher will fail on any directory that contains more than 127 files. The Default watcher on the other hand is slower but can handle large directories without any modification to the system's configuration. > As wrote above, I'm not using module in subject, but I have concerns > for changing defaults.. I'm asking as I feel I'm missing something to > understand reasoning. I doubt that the defaults are changed for anybody. On the contrary, so far the port doesn't depend on p5-IO-KQueue, which suggests that whoever created this port didn't consider the KQueue-based watcher. Actually, if the p5-IO-KQueue package is installed the regression tests of the current port fail because of a bug in KQueue.pm. My guess is that the port was merely created to satisfy dependencies. Also, if p5-IO-KQueue is pulled in by some other package, the current p5-File-ChangeNotify package might suddenly start to fail because the installation of p5-IO-KQueue changes the default from the Default watcher to the KQueue watcher. This is not what users expect. Furthermore, it's not possible to automatically decide at runtime whether to use the Default or the KQueue watcher. When the watcher is instantiated the size of the directory is not known. Also, directories might grow during runtime. Using the KQueue-based watcher is dangerous unless you know for sure that the size of the watched directories will never exceed your resource limits. A hybrid watcher that tries to use KQueue and falls back to the Default mechanism if a threshold of available file descriptors is reached could make sense though. But my goal is just to get this port updated so that eventually Moose can be updated.
Re: UPDATE: devel/p5-File-ChangeNotify
On Sat, Jan 01, 2011 at 01:23:12PM +0100, Andreas Vögele wrote: > It seems that the port so far didn't take into account that the > p5-IO-KQueue package could be installed on the system. Since the > KQueue-based file watcher quickly exceeds the maximum number of open > files in a default OpenBSD installation, I changed ChangeNotify.pm to > prefer the Default watcher even if IO::KQueue is available. I think this > is more reasonable than to ask the users to raise their openfiles and > maxfiles limits from 128 and 7030 to much higher values. Ok. What about users, who altered their system already, and have raised kern.maxfiles and openfiles-cur in login.conf(5) for example, for gam_server (see gamin package). Not that I am using ChangeNotify.pm, but what is default watcher in that module? Which watcher is more efficient? Does your change (to not use IO::KQueue as default watcher) help the user of ChangeNotify.pm in any way? As wrote above, I'm not using module in subject, but I have concerns for changing defaults.. I'm asking as I feel I'm missing something to understand reasoning. -- best regards q#
