ports/162049: The Ports tree lacks a framework to restart services
Hi folks,
As crees@ suggested, I'm sending an email to ports@ about this.
What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent. As mentioned in the PR:
- If I upgrade Apache, MySQL or PostgreSQL, it does not restart the
service, meaning it won't use the freshly installed daemon. This has
potential security issues.
- If I upgrade Dovecot, it shuts it down during the upgrade, but won't
restart it. This means that I have to watch portmaster to complete and
must not forget to restart Dovecot afterwards.
My question is whether anyone has ever attempted to improve the
integration with rc-scripts? In the PR I propose something along these
lines:
We know exactly which ports install rc scripts (USE_RC_SUBR).
Why not run `/usr/local/etc/rc.d/${FOO} status' and
`/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
on the return value of the first, we can run
`/usr/local/etc/rc.d/${FOO} start' after installation.
--
Ed Schouten e...@80386.nl
WWW: http://80386.nl/
pgpPIcEFLSqiZ.pgp
Description: PGP signature
Re: [UPDATE] Re: Update on ports on 10.0
On Fri, Oct 21, 2011 at 12:44:34PM +0300, Ion-Mihai Tetcu wrote: What, on the other hand, makes sense is to have the fix that should include: a) a KNOB (WITH_FBSD10_FIX or similar), b) that only is run from bsd.port.mk when OSVERSION100 c) runs the latest version of the above patch. The KNOB's existence allow us to turn on the fix only for broken ports, and easily know what these broken ports are -- so we can poke maintainers from time to time about upstream fixes, ... Erwin is currently running a build on i386-10 with this and the following patches: - bsd.port.mk patch from beat (based on ed@, jilles@ and stas@ patches) - python patch from beat - python patch from linimon - WITH_FBSD10_FIX in: - textproc/expat2 - devel/pcre - devel/libtool - audio/libogg Results by Monday. These patches have now been committed to the tree, notably with lang/python27 missing in the above list but was included as well. There have been some proposals already and we can now incrementally improve the workaround and, more importantly, start fixing individual ports. Please note that the patch tries to balance between being a general enough fix to make it easy to get a working system running while not just swiping the whole issue under the rug and forget about it until the next release cycle. Make sure to send any fixes upstream to the hack can be removed from the ports again. Thanks for all your patience and thanks for all those involved, especially beat who sent many patches and improvements. Erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/162049: The Ports tree lacks a framework to restart services
hello
On Thu, Oct 27, 2011 at 11:15 AM, Ed Schouten e...@80386.nl wrote:
We know exactly which ports install rc scripts (USE_RC_SUBR).
Why not run `/usr/local/etc/rc.d/${FOO} status' and
`/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
on the return value of the first, we can run
`/usr/local/etc/rc.d/${FOO} start' after installation.
Here is a link to the PR, for people who want it easy:
http://www.freebsd.org/cgi/query-pr.cgi?pr=162049
Shouldn't you be using 'service FOO stop' instead? See service(8).
Personally, I prefer the port upgrade process to NOT touch my running
services at all.
In cases where it can't be avoided, I'm prepared to manually handle
services that needs to be restarted after an upgrade.
As you probably are aware of already, there are also security concerns
with automatically starting a newly installed version of a program.
I'm only running FreeBSD for my personal use, on a limited number of machines.
If I was working with a larger number of machines, or needed an
automated solution, I would look into tools like sysutils/cfengine3
HTH
--
Regards,
Torfinn Ingolfsen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/162049: The Ports tree lacks a framework to restart services
On 10/27/11 11:15, Ed Schouten wrote: I believe you have a point there. What really bothers me when I use the FreeBSD Ports tree on one of my systems, is that the behaviour of dealing with services is quite inconsistent. As mentioned in the PR: - If I upgrade Apache, MySQL or PostgreSQL, it does not restart the service, meaning it won't use the freshly installed daemon. This has potential security issues. - If I upgrade Dovecot, it shuts it down during the upgrade, but won't restart it. This means that I have to watch portmaster to complete and must not forget to restart Dovecot afterwards. So does dhcpserver, unfortunately. I'll also add a *really minor* glitch: during upgrade, some ports will leave their daemons running, but somehow break the rc.d scripts, so that you need to manually kill them before you can correctly restart them (e.g. saslauthd). IMVVVHO, I'd be pleased to have the port upgrading process do nothing and leave it to me to restart anything required. I'm inclined to think that, if some port upgrade process stops a daemon, there must be a reason behind this: possibly the port wouldn't upgrade properly otherwise. In this case I'd really like the port to stop and wait for me to press enter just before doing this. The reason is simple: if I launch a portupgrade -a, taking potentially days, services will stop over time without any way for me to predict when and I can't possibly watch for hours. If they just stopped before killing a service, I could look from time to time and be prepared to restart it in a few minutes (just the time for a single port's make install). Just my two cents... bye av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [UPDATE] Re: Update on ports on 10.0
Erwin Lansing wrote on 27.10.2011 14:21: On Fri, Oct 21, 2011 at 12:44:34PM +0300, Ion-Mihai Tetcu wrote: What, on the other hand, makes sense is to have the fix that should include: a) a KNOB (WITH_FBSD10_FIX or similar), b) that only is run from bsd.port.mk when OSVERSION100 c) runs the latest version of the above patch. The KNOB's existence allow us to turn on the fix only for broken ports, and easily know what these broken ports are -- so we can poke maintainers from time to time about upstream fixes, ... Erwin is currently running a build on i386-10 with this and the following patches: - bsd.port.mk patch from beat (based on ed@, jilles@ and stas@ patches) - python patch from beat - python patch from linimon - WITH_FBSD10_FIX in: - textproc/expat2 - devel/pcre - devel/libtool - audio/libogg Results by Monday. These patches have now been committed to the tree, notably with lang/python27 missing in the above list but was included as well. There have been some proposals already and we can now incrementally improve the workaround and, more importantly, start fixing individual ports. Please note that the patch tries to balance between being a general enough fix to make it easy to get a working system running while not just swiping the whole issue under the rug and forget about it until the next release cycle. Make sure to send any fixes upstream to the hack can be removed from the ports again. Thanks for all your patience and thanks for all those involved, especially beat who sent many patches and improvements. Erwin About devel/libtool fix. Why to not update it to 2.4.2 where this was fixed upstream? I mean http://bugs.freebsd.org/162012 -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/162049: The Ports tree lacks a framework to restart services
On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
Hi folks,
As crees@ suggested, I'm sending an email to ports@ about this.
What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent. As mentioned in the PR:
I agree inconsistency is a problem that could be addressed, but I don't
particularly agree with some of your statements.
- If I upgrade Apache, MySQL or PostgreSQL, it does not restart the
service, meaning it won't use the freshly installed daemon. This has
potential security issues.
I'd prefer that no services are started or stopped automatically, unless
absolutely necessary for the upgrade.
- If I upgrade Dovecot, it shuts it down during the upgrade, but won't
restart it. This means that I have to watch portmaster to complete and
must not forget to restart Dovecot afterwards.
Unless it is absolutely necessary to stop and restart dovecot during an
upgrade I would like to see this removed.
My question is whether anyone has ever attempted to improve the
integration with rc-scripts? In the PR I propose something along these
lines:
We know exactly which ports install rc scripts (USE_RC_SUBR).
Why not run `/usr/local/etc/rc.d/${FOO} status' and
`/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
on the return value of the first, we can run
`/usr/local/etc/rc.d/${FOO} start' after installation.
I'm of the opinion that ports/packages should not touch running services
unless absolutely necessary.
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: UPDATING 20111016 and net/linphone-base -- can not be built.
On Thursday 27 October 2011 16:02:58 Alan Hicks wrote: Clean build install on i386 RELEASE-8.2 with patch. Thank you! -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla You are dishonest, but never to the point of hurting a friend. signature.asc Description: This is a digitally signed message part.
Re: UPDATING 20111016 and net/linphone-base -- can not be built.
On 24/10/2011 08:06, Alberto Villa wrote: On Wed, Oct 19, 2011 at 9:25 AM, Alberto Villaavi...@freebsd.org wrote: Ok, ortp is just an old version of the one in linphone-base. I'll try to build kopete with linphone-base and, should it work, I'll replace the dependency. kopete builds fine, so I'm about to replace the dependency. I can try libjingle on i386, too. Can anyone test the attached patch for me on i386? # cd /usr/ports/net-im/libjingle patch $thepatch Clean build install on i386 RELEASE-8.2 with patch. Thanks, Alan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/162049: The Ports tree lacks a framework to restart services
On 27.10.2011 15:04, Wesley Shields wrote:
I agree inconsistency is a problem that could be addressed, but I don't
particularly agree with some of your statements.
Consistency is important, and I agree with Wesley that we should
consistently do nothing, instead of consistently stopping/starting
daemons.
- If I upgrade Dovecot, it shuts it down during the upgrade, but won't
restart it. This means that I have to watch portmaster to complete and
must not forget to restart Dovecot afterwards.
Unless it is absolutely necessary to stop and restart dovecot during an
upgrade I would like to see this removed.
I have a hard time imagining a situation where this is the case,
and again I agree with Wesley, I would also like to see it removed.
The dovecot stopping thing has bitten me more than once.
My question is whether anyone has ever attempted to improve the
integration with rc-scripts? In the PR I propose something along these
lines:
We know exactly which ports install rc scripts (USE_RC_SUBR).
Why not run `/usr/local/etc/rc.d/${FOO} status' and
`/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
on the return value of the first, we can run
`/usr/local/etc/rc.d/${FOO} start' after installation.
This can fail in so many unexpected ways that IMO it is much better
to do nothing at all, and leave it up to the sysadmin to decide when
to restart the daemon.
If anything like this is needed, perhaps we could add a message after
upgrading a port which installs an RC script, mentioning that the
sysadmin needs to restart the daemon manually (whenever appropriate)
in order to run the new version.
Best regards,
Thomas Steen Rasmussen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
chromium 15 not building with heimdal 1.4.1
(I will file a PR as well so this is not lost) This is the first time I have seen this error. I always have a local heimdal port (1.4) or a more up to date local build from source (e.g. 1.5.1) installed, and have regularly built chromium without any problems, so I'm thinking this must be a new issue. Upstream support for GSSAPI on Linux and BSD (OS/X) is only about a year old - which would equate to the older releases that were in ports until recently. Manually editing WRKDIR/net/http/http_auth_gssapi_posix.h (included from line 5 of net/http/http_auth_gssapi_posix.cc) so that it grabs BASE heimdal from /usr/include/gssapi/gssapi.h allows the port to build, but I'm not sure this is the best solution. The BASE version of heimdal is quite old and there are a number of ports that depend on the security/heimdal port (which is at version 1.4) so it would be best if www/chromium built properly against these newer versions. cheers, The latest chromium port (15.*) won't build with a locally installed heimdal, failing with these errors (clang): /usr/local/include/gssapi/gssapi.h:351:30: note: instantiated from: #define GSS_C_NT_ANONYMOUS (__gss_c_nt_anonymous_oid_desc) net/http/http_auth_gssapi_posix.cc:58:9: error: redefinition of '__gss_c_nt_user_name_oid_desc' with a different type gss_OID GSS_C_NT_USER_NAME = GSS_C_NT_USER_NAME_VAL; ^ In file included from net/http/http_auth_gssapi_posix.cc:5: In file included from ./net/http/http_auth_gssapi_posix.h:9: In file included from /usr/local/include/gssapi.h:39: /usr/local/include/gssapi/gssapi.h:276:30: note: instantiated from: #define GSS_C_NT_USER_NAME (__gss_c_nt_user_name_oid_desc) ^ /usr/local/include/gssapi/gssapi.h:275:41: note: previous definition is here extern GSSAPI_LIB_VARIABLE gss_OID_desc __gss_c_nt_user_name_oid_desc; ^ net/http/http_auth_gssapi_posix.cc:59:9: error: redefinition of '__gss_c_nt_machine_uid_name_oid_desc' with a different type gss_OID GSS_C_NT_MACHINE_UID_NAME = GSS_C_NT_MACHINE_UID_NAME_VAL; ^ In file included from net/http/http_auth_gssapi_posix.cc:5: In file included from ./net/http/http_auth_gssapi_posix.h:9: In file included from /usr/local/include/gssapi.h:39: /usr/local/include/gssapi/gssapi.h:290:37: note: instantiated from: #define GSS_C_NT_MACHINE_UID_NAME (__gss_c_nt_machine_uid_name_oid_desc) ^ /usr/local/include/gssapi/gssapi.h:289:41: note: previous definition is here extern GSSAPI_LIB_VARIABLE gss_OID_desc __gss_c_nt_machine_uid_name_oid_desc; ^ net/http/http_auth_gssapi_posix.cc:60:9: error: redefinition of '__gss_c_nt_string_uid_name_oid_desc' with a different type gss_OID GSS_C_NT_STRING_UID_NAME = GSS_C_NT_STRING_UID_NAME_VAL; ^ In file included from net/http/http_auth_gssapi_posix.cc:5: In file included from ./net/http/http_auth_gssapi_posix.h:9: In file included from /usr/local/include/gssapi.h:39: /usr/local/include/gssapi/gssapi.h:304:36: note: instantiated from: #define GSS_C_NT_STRING_UID_NAME (__gss_c_nt_string_uid_name_oid_desc) ^ /usr/local/include/gssapi/gssapi.h:303:41: note: previous definition is here '__gss_c_nt_hostbased_service_x_oid_desc' with a different type gss_OID GSS_C_NT_HOSTBASED_SERVICE_X = GSS_C_NT_HOSTBASED_SERVICE_X_VAL; ^ In file included from net/http/http_auth_gssapi_posix.cc:5: In file included from ./net/http/http_auth_gssapi_posix.h:9: In file included from /usr/local/include/gssapi.h:39: /usr/local/include/gssapi/gssapi.h:324:40: note: instantiated from: #define GSS_C_NT_HOSTBASED_SERVICE_X (__gss_c_nt_hostbased_service_x_oid_desc) ^ /usr/local/include/gssapi/gssapi.h:323:41: note: previous definition is here extern GSSAPI_LIB_VARIABLE gss_OID_desc __gss_c_nt_hostbased_service_x_oid_desc; ^ net/http/http_auth_gssapi_posix.cc:62:9: error: redefinition of '__gss_c_nt_hostbased_service_oid_desc' with a different type gss_OID GSS_C_NT_HOSTBASED_SERVICE = GSS_C_NT_HOSTBASED_SERVICE_VAL; ^ In file included from net/http/http_auth_gssapi_posix.cc:5: In file included from ./net/http/http_auth_gssapi_posix.h:9: In file included from /usr/local/include/gssapi.h:39: /usr/local/include/gssapi/gssapi.h:338:38: note: instantiated from: #define GSS_C_NT_HOSTBASED_SERVICE (__gss_c_nt_hostbased_service_oid_desc) ^ /usr/local/include/gssapi/gssapi.h:337:41: note: previous definition is here extern GSSAPI_LIB_VARIABLE gss_OID_desc __gss_c_nt_hostbased_service_oid_desc; ^ net/http/http_auth_gssapi_posix.cc:63:9: error: redefinition of '__gss_c_nt_anonymous_oid_desc' with a different type gss_OID GSS_C_NT_ANONYMOUS = GSS_C_NT_ANONYMOUS_VAL; ^ In file included from
Re: ports/162049: The Ports tree lacks a framework to restart services
On Thursday, October 27, 2011 11:15:00 AM Ed Schouten wrote:
Hi folks,
As crees@ suggested, I'm sending an email to ports@ about this.
What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent. As mentioned in the PR:
- If I upgrade Apache, MySQL or PostgreSQL, it does not restart the
service, meaning it won't use the freshly installed daemon. This has
potential security issues.
- If I upgrade Dovecot, it shuts it down during the upgrade, but won't
restart it. This means that I have to watch portmaster to complete and
must not forget to restart Dovecot afterwards.
My question is whether anyone has ever attempted to improve the
integration with rc-scripts? In the PR I propose something along these
lines:
We know exactly which ports install rc scripts (USE_RC_SUBR).
Why not run `/usr/local/etc/rc.d/${FOO} status' and
`/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
on the return value of the first, we can run
`/usr/local/etc/rc.d/${FOO} start' after installation.
portupgrade provides basic support for restarting services via pkgtools.conf:
BEFOREDEINSTALL = {
# Automatically stop the service for each package that has a
# rc script enabled
'*' = proc { |origin|
cmd_stop_rc(origin)
},
}
AFTERINSTALL = {
# Automatically start the server for each package that
# installs a rc file enabled
'*' = proc { |origin|
cmd_start_rc(origin)
},
}
Keeping a service running during/after upgrade is potentielly unsafe. E.g., it
might be looking for files that have just been removed or modified in an
incompatible way.
Keeping a service running after deletion (no reinstall) also seems like a
really bad idea to me.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/162049: The Ports tree lacks a framework to restart services
Wesley Shields wrote:
On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
Hi folks,
As crees@ suggested, I'm sending an email to ports@ about this.
What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent. As mentioned in the PR:
I agree inconsistency is a problem that could be addressed, but I don't
particularly agree with some of your statements.
- If I upgrade Apache, MySQL or PostgreSQL, it does not restart the
service, meaning it won't use the freshly installed daemon. This has
potential security issues.
I'd prefer that no services are started or stopped automatically, unless
absolutely necessary for the upgrade.
- If I upgrade Dovecot, it shuts it down during the upgrade, but won't
restart it. This means that I have to watch portmaster to complete and
must not forget to restart Dovecot afterwards.
Also Smartd from SmartMonTools and MySQL are stopped during upgrade process.
- There are some ports touching user modified files on install /
uninstall. For example some Apache modules are touching httpd.conf which
is not good in some cases. If I upgrade mod_bw or mod_proctitle, it
removes (comment out) the LoadModule line on uninstall phase and not
enable it again on install phase of new version. So I must manually edit
httpd.conf after each upgrade before Apache restart.
Unless it is absolutely necessary to stop and restart dovecot during an
upgrade I would like to see this removed.
I think the main problem is that there is no difference between
Uninstall and Upgrade (from ports perspective).
It can be OK to shutdown daemon on uninstall. But somebody wants to
restart services on upgrade and somebody wants to keep them running.
Both have pros and cons.
As mentioned above with Apache modules case, if there will be way to
distinguish between uninstall and upgrade, then there will be ways to
handle this problems more carefully.
But intil then I vote for removing all custom stop / restart / edit
files on per port basis - because it is inconsistent and unpredictable.
My question is whether anyone has ever attempted to improve the
integration with rc-scripts? In the PR I propose something along these
lines:
We know exactly which ports install rc scripts (USE_RC_SUBR).
Why not run `/usr/local/etc/rc.d/${FOO} status' and
`/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
on the return value of the first, we can run
`/usr/local/etc/rc.d/${FOO} start' after installation.
I'm of the opinion that ports/packages should not touch running services
unless absolutely necessary.
I think that the best would be to do some user configurable hooks on
install / uninstall / upgrade actions in similar way as portupgrade does
it. (e.g. somebody may want to stop another service before upgrade
[restart] of mysql-server)
Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/162049: The Ports tree lacks a framework to restart services
On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote: Hi folks, As crees@ suggested, I'm sending an email to ports@ about this. What really bothers me when I use the FreeBSD Ports tree on one of my systems, is that the behaviour of dealing with services is quite inconsistent. As mentioned in the PR: - If I upgrade Apache, MySQL or PostgreSQL, it does not restart the service, meaning it won't use the freshly installed daemon. This has potential security issues. - If I upgrade Dovecot, it shuts it down during the upgrade, but won't restart it. This means that I have to watch portmaster to complete and must not forget to restart Dovecot afterwards. imho the consistency should be done by removing the autostopping stuff and auto-upgrading stuff. we have no way to be sure it will be safe at all as we don't know from which version of the previous software it has been upgraded, I can't imagine how much data corruption it would lead to. restarting the services is the goal of the system administrator it shouldn't been automated at all. I would hate that freebsd-update automatically reboot my box because it upgraded the kernel, the same way I don't want packages to restart my services, it can leads to more problem that it can solve. Administrators should know what they do, the only thing that maybe can be done is a recommandation to tell the upgrader that he should restart some services. My 2cts, Bapt pgpjIWvyhOs7B.pgp Description: PGP signature
Re: ports/162049: The Ports tree lacks a framework to restart services
On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
Hi folks,
As crees@ suggested, I'm sending an email to ports@ about this.
What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent.
My question is whether anyone has ever attempted to improve the
integration with rc-scripts? In the PR I propose something along these
lines:
We know exactly which ports install rc scripts (USE_RC_SUBR).
Why not run `/usr/local/etc/rc.d/${FOO} status' and
`/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
on the return value of the first, we can run
`/usr/local/etc/rc.d/${FOO} start' after installation.
If all of that is contingent upon a boolean knob the admin can set,
something like NO_RESTART_SERVICES, I suspect everyone could get
what they want and the bikeshed would be limitted to what the default
for that boolean should be.
The people who don't want the services restarted automagically can
set it and, once things use the new ports framewoork properly, not
have to worry about suprises. The people who want everything to
restarted as soon as possible can set the knob the other way.
It could help keep our less sophisticated users from continuing to
run vulerable versions of software after they think they have done
what is needed to get the patched software. The sophisticated users
would still be free to choose which foot to shoot.
A side effect might, eventually, be to encourage ports maintainers
to analyse their ported software for incompatible config changes
so that they can programatically halt the install and output a
warning message before attempting to stop the old daemon then
upgrading while a likely un-usable config is in place.
I see it as win, win, if there is a knob.
I do not like either option without a knob, depending on the box
we are talking about.
--
Scott LambertKC5MLE Unix SysAdmin
lamb...@lambertfam.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/162049: The Ports tree lacks a framework to restart services
Quoth Scott Lambert on Thursday, 27 October 2011:
On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
Hi folks,
As crees@ suggested, I'm sending an email to ports@ about this.
What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent.
My question is whether anyone has ever attempted to improve the
integration with rc-scripts? In the PR I propose something along these
lines:
We know exactly which ports install rc scripts (USE_RC_SUBR).
Why not run `/usr/local/etc/rc.d/${FOO} status' and
`/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
on the return value of the first, we can run
`/usr/local/etc/rc.d/${FOO} start' after installation.
If all of that is contingent upon a boolean knob the admin can set,
something like NO_RESTART_SERVICES, I suspect everyone could get
what they want and the bikeshed would be limitted to what the default
for that boolean should be.
The people who don't want the services restarted automagically can
set it and, once things use the new ports framewoork properly, not
have to worry about suprises. The people who want everything to
restarted as soon as possible can set the knob the other way.
It could help keep our less sophisticated users from continuing to
run vulerable versions of software after they think they have done
what is needed to get the patched software. The sophisticated users
would still be free to choose which foot to shoot.
A side effect might, eventually, be to encourage ports maintainers
to analyse their ported software for incompatible config changes
so that they can programatically halt the install and output a
warning message before attempting to stop the old daemon then
upgrading while a likely un-usable config is in place.
I see it as win, win, if there is a knob.
I do not like either option without a knob, depending on the box
we are talking about.
+1 for this idea.
+10 for The sophisticated users would still be free to choose which foot
to shoot.
--
.O. | Sterling (Chip) Camden | http://camdensoftware.com
..O | sterl...@camdensoftware.com | http://chipsquips.com
OOO | 2048R/D6DBAF91 | http://chipstips.com
pgp8LT4IzHYN8.pgp
Description: PGP signature
INDEX build failed for 7.x
INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: rubygem-sinatra-1.3.1: no entry for /usr/ports/www/rubygem-rack-protection Committers on the hook: osa stephen swills Most recent CVS update was: U databases/redis/Makefile U databases/redis/distinfo U devel/Makefile U devel/rubygem-jruby-jars/Makefile U devel/rubygem-jruby-jars/distinfo U devel/rubygem-minitest/Makefile U devel/rubygem-minitest/distinfo U devel/rubygem-rack-protection/Makefile U devel/rubygem-rack-protection/distinfo U devel/rubygem-rack-protection/pkg-descr U devel/rubygem-simple_form/Makefile U devel/rubygem-simple_form/distinfo U devel/rubygem-turn/Makefile U devel/rubygem-turn/distinfo U devel/rubygem-turn/pkg-descr U devel/rubygem-warden/Makefile U devel/rubygem-warden/distinfo U math/octave-forge-plot/Makefile U math/octave-forge-plot/distinfo U www/rubygem-cuba/Makefile U www/rubygem-cuba/distinfo U www/rubygem-sinatra/Makefile U www/rubygem-sinatra/distinfo ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: INDEX build failed for 7.x
Fixed, sorry about that. INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: rubygem-sinatra-1.3.1: no entry for /usr/ports/www/rubygem-rack-protection Committers on the hook: osa stephen swills Most recent CVS update was: U databases/redis/Makefile U databases/redis/distinfo U devel/Makefile U devel/rubygem-jruby-jars/Makefile U devel/rubygem-jruby-jars/distinfo U devel/rubygem-minitest/Makefile U devel/rubygem-minitest/distinfo U devel/rubygem-rack-protection/Makefile U devel/rubygem-rack-protection/distinfo U devel/rubygem-rack-protection/pkg-descr U devel/rubygem-simple_form/Makefile U devel/rubygem-simple_form/distinfo U devel/rubygem-turn/Makefile U devel/rubygem-turn/distinfo U devel/rubygem-turn/pkg-descr U devel/rubygem-warden/Makefile U devel/rubygem-warden/distinfo U math/octave-forge-plot/Makefile U math/octave-forge-plot/distinfo U www/rubygem-cuba/Makefile U www/rubygem-cuba/distinfo U www/rubygem-sinatra/Makefile U www/rubygem-sinatra/distinfo ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
INDEX now builds successfully on 7.x
___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [kde-freebsd] k3b-kde4 fails to build on Beta3
On Sunday 09 October 2011 08:22:02 Robert wrote: /usr/ports/sysutils/k3b-kde4/work/k3b-2.0.2/libk3bdevice/k3bscsicommand.cpp :186: /usr/ports/sysutils/k3b-kde4/work/k3b-2.0.2/libk3bdevice/k3bscsicommand_bsd .cpp: In member function 'int K3b::Device::ScsiCommand::transport(K3b::Device::TransportDirection, void*, size_t)': /usr/ports/sysutils/k3b-kde4/work/k3b-2.0.2/libk3bdevice/k3bscsicommand_bsd .cpp:108: error: 'struct scsi_sense_data' has no member named 'flags' [snip] I've fixed this upstream and in our area51 repository. If you're wiling to give it a try, copy [1] into your k3b-kde4/files directory in your ports tree. If things work fine, I'll commit it to ports in a few days. [1] http://area51.pcbsd.org/trunk/area51/PORTS/sysutils/k3b-kde4/files/patch-libk3bdevice-k3bscsicommandbsd.cpp ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
