Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Robert Watson [EMAIL PROTECTED] writes: (1) Combine / and /usr into a single file system by default, and add /usr/local/etc/rc.d to the search order, with appropriate hacks to handle old-style scripts. The devil will be in the bikeshed, but the implementation is easy, except for the bit where we explain that NFS-mounted /usr/local won't work too well. I'd discourage that. It's fairly intrusive and breaks existing setups. I'm NOT going to repartition and reinstall! (2) Reevaluate the order at routine points in the boot where new scripts might now be available (due to file system mounts or whatever). Essentially insert the new cards into the deck, and shuffle. This requires rethinking of our current approach, which assumes a static order is created once at the start of the boot by rcorder(8). The devil will be in the big picture *and* the details of the implementation. I don't think there shall be devils in the implementation details. I admit not having looked at rcorder yet, but dependencies can be passed on from one rcorder run to the next, through the usual process environment. (3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a new directory that third party applications are allowed to modify during install, and that will be present for the creation of the static ordering by rcorder(8) early in the boot. The devil will be in the bikeshed, but the implementation is easy. /etc/local/rc.d might work, it's quite similar to the /etc/opt approach configuration stuff for /opt applications on Linux. I'm actually leaning towards (2) as being the best solution, as it's easy and functional. Seconded from the user's view. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Sun, Nov 30, 2003 at 03:41:33AM +0100, Oliver Eikemeier wrote: Kris Kennaway wrote: On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Smorgrav wrote: Andreas Klemm [EMAIL PROTECTED] writes: I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ That is very, very bad. I wish we had some kind of ports QA team :( Well, er, a number of us do essentially nothing BUT ports QA. I'm sorry if I did something disturbing, and I'm surely interested in ports tree QA! I know that I violate the prefix, and did that on purpose, see my comment in net/opendldap2[012]-server/Makefile: # currently the only way to participate in rcorder(8) I posted PR conf/56736: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736 but nobody seemed to care, and I had enough construction areas that I didn't wanted to start a discussion about that. The point is that we might want to have some port services to start early. That gives the possibility to move functionality from the base system to ports, which I believe isn't bad. I can simply change the openldap ports so that they are nice and quiet, but IMHO that does not really solve a problem. But please correct me if my arguments are too simple-minded. What about simply putting a number in front of the script, I didn't check but am really certain that we start scripts something like this: cd $LOCALBASE/etc/rc.d for i in *.sh --- here you get an alphabetically sort order ! do if [ -x $i ]; then /bin/sh $i start fi done So this would be sufficient to start slapd before slurpd: /usr/local/etc/rc.d/001.slapd.sh /usr/local/etc/rc.d/002.slurpd.sh or alternatively /usr/local/etc/rc.d/openldap-01-slapd.sh /usr/local/etc/rc.d/openldap-02-slurpd.sh We already have things like: 000.mysql-client.sh 000.pkgtools.sh 000.wine.sh 010.pgsql.sh Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Andreas Klemm wrote: On Sun, Nov 30, 2003 at 03:41:33AM +0100, Oliver Eikemeier wrote: Kris Kennaway wrote: On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Smorgrav wrote: Andreas Klemm [EMAIL PROTECTED] writes: I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ That is very, very bad. I wish we had some kind of ports QA team :( Well, er, a number of us do essentially nothing BUT ports QA. I'm sorry if I did something disturbing, and I'm surely interested in ports tree QA! I know that I violate the prefix, and did that on purpose, see my comment in net/opendldap2[012]-server/Makefile: # currently the only way to participate in rcorder(8) I posted PR conf/56736: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736 but nobody seemed to care, and I had enough construction areas that I didn't wanted to start a discussion about that. The point is that we might want to have some port services to start early. That gives the possibility to move functionality from the base system to ports, which I believe isn't bad. I can simply change the openldap ports so that they are nice and quiet, but IMHO that does not really solve a problem. But please correct me if my arguments are too simple-minded. What about simply putting a number in front of the script, I didn't check but am really certain that we start scripts something like this: cd $LOCALBASE/etc/rc.d for i in *.sh --- here you get an alphabetically sort order ! do if [ -x $i ]; then /bin/sh $i start fi done So this would be sufficient to start slapd before slurpd: /usr/local/etc/rc.d/001.slapd.sh /usr/local/etc/rc.d/002.slurpd.sh or alternatively /usr/local/etc/rc.d/openldap-01-slapd.sh /usr/local/etc/rc.d/openldap-02-slurpd.sh We already have things like: 000.mysql-client.sh 000.pkgtools.sh 000.wine.sh 010.pgsql.sh I don't care whether slapd or slurpd starts first, I even don't care when slurpd starts. I want to start ldapd early in the boot process to supports services like nss_ldap and mail. I did things differently e.g. in net/rsync, because rsync does not provide any services that base services depend on. -Oliver ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Sun, Nov 30, 2003 at 12:43:06PM +0100, Oliver Eikemeier wrote: I don't care whether slapd or slurpd starts first, I even don't care when slurpd starts. I want to start ldapd early in the boot process to supports services like nss_ldap and mail. I did things differently e.g. in net/rsync, because rsync does not provide any services that base services depend on. Ah understand .. then the situation is like with DHCP in FreeBSD. So ot seems to me, that the needed part of ldap has to go into src/contrib ?! Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
I have a better idea, then we perhaps need something like a wrapper script that is part of the FreeBSD basic system under /etc/rc.d that checks for the start script under $LOCALBASE/etc/rc.d and starts it very early. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Oliver Eikemeier wrote: The reason I did this was to support services like mail and nss_ldap. I really like to be prefix safe, PR conf/56736 relates to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736 I agree that there should be a better solution, and already asked Mike Makonnen [EMAIL PROTECTED] about it, but nobody seemed to care. IMHO not participating in rcorder(8) makes the packing list pettier and avoids an ugly hack, which is good, but restrains functionality. I like the idea of account managed in an centralized LDAP directory very much. So, do you still think the scripts should not participate in rcorder(8)? It's easy to change the ports, but this is probably not the right fix. -Oliver I guess I don't see the problem. What is wrong with ports adding startup scripts to /etc/rc.d? For certain ports, that is the only way to get the startup dependencies right (like making sure openldap or postgresql starts before your mail system). This will become more important as more of the base system moves to ports/packages. Just refine the note in UPDATING to specifically state which startup scripts to remove, rather than rm -rf /etc/rc.d/*. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Andreas Klemm wrote: What about simply putting a number in front of the script, I didn't check but am really certain that we start scripts something like this: cd $LOCALBASE/etc/rc.d for i in *.sh --- here you get an alphabetically sort order ! do if [ -x $i ]; then /bin/sh $i start fi done So this would be sufficient to start slapd before slurpd: /usr/local/etc/rc.d/001.slapd.sh /usr/local/etc/rc.d/002.slurpd.sh or alternatively /usr/local/etc/rc.d/openldap-01-slapd.sh /usr/local/etc/rc.d/openldap-02-slurpd.sh We already have things like: 000.mysql-client.sh 000.pkgtools.sh 000.wine.sh 010.pgsql.sh Andreas /// That works fine if you are only concerned about startup ordering for things in /usr/local/etc/rc.d. Although it would be better if we could use rcorder style dependency ordering here as well. But it doesn't help if you need a port to start earlier than something in the base. This could happen if you've replaced sendmail with postfix, and use maps from a remote database (openldap, postgresql, etc). I'm sure there are other examples as well (nss_ldap, etc). Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Sun, 30 Nov 2003, Andreas Klemm wrote: I have a better idea, then we perhaps need something like a wrapper script that is part of the FreeBSD basic system under /etc/rc.d that checks for the start script under $LOCALBASE/etc/rc.d and starts it very early. Hmm. I talked with Gordon about this issue some last night, but he pointed out a snag: most installs of FreeBSD place /usr on a separate partition from /. The rcNG ordering decision is made before /usr is mounted, as /usr is mounted as part of the pieces kicked off by rc.d. So it would be a fairly large departure from the current implementation of the rcNG code to reevaluate the ordering once more directories were available in which to find scripts to run. Not that it's not doable, but we need to think about it carefully (and, unfortunately, it's not as easy as simply adding /usr/local/etc/rc.d to the list..) Having wrapper scripts in /etc/rc.d can work, but it means we don't get the full benefits of ordering, and that any ordering information has to be in the wrapper, not in the bit installed by the port in /usr/local... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Sun, Nov 30, 2003 at 10:45:40AM -0500, Richard Coleman wrote: Oliver Eikemeier wrote: The reason I did this was to support services like mail and nss_ldap. I really like to be prefix safe, PR conf/56736 relates to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736 I agree that there should be a better solution, and already asked Mike Makonnen [EMAIL PROTECTED] about it, but nobody seemed to care. IMHO not participating in rcorder(8) makes the packing list pettier and avoids an ugly hack, which is good, but restrains functionality. I like the idea of account managed in an centralized LDAP directory very much. So, do you still think the scripts should not participate in rcorder(8)? It's easy to change the ports, but this is probably not the right fix. -Oliver I guess I don't see the problem. What is wrong with ports adding startup scripts to /etc/rc.d? For certain ports, that is the only way to get the startup dependencies right (like making sure openldap or postgresql starts before your mail system). This will become more important as more of the base system moves to ports/packages. Just refine the note in UPDATING to specifically state which startup scripts to remove, rather than rm -rf /etc/rc.d/*. As I wrote im my previous mail we could import wrapper scripts for such basic services, since there are only few services that are so generic, that they have to be available so early in boot order. I strongly would dislike creating ports to install stuff under /etc/whatever. This would start to violate things for what I liked FreeBSD for all these many years and I hope/think other have the same feeling concerning this. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Sun, Nov 30, 2003 at 11:31:34AM -0500, Robert Watson wrote: On Sun, 30 Nov 2003, Andreas Klemm wrote: I have a better idea, then we perhaps need something like a wrapper script that is part of the FreeBSD basic system under /etc/rc.d that checks for the start script under $LOCALBASE/etc/rc.d and starts it very early. Hmm. I talked with Gordon about this issue some last night, but he pointed out a snag: most installs of FreeBSD place /usr on a separate partition from /. The rcNG ordering decision is made before /usr is mounted, as /usr is mounted as part of the pieces kicked off by rc.d. So it would be a fairly large departure from the current implementation of the rcNG code to reevaluate the ordering once more directories were available in which to find scripts to run. Not that it's not doable, but we need to think about it carefully (and, unfortunately, it's not as easy as simply adding /usr/local/etc/rc.d to the list..) Having wrapper scripts in /etc/rc.d can work, but it means we don't get the full benefits of ordering, and that any ordering information has to be in the wrapper, not in the bit installed by the port in /usr/local... Sh** I should have read your mail earlier, b4 writing a f'up ... Its completely true. On FreeBSD servers I have / and /usr always on a separate partition. Only Solaris I install differently, to have / and /usr on one partition, since Solaris has only less if not soon _none_ statically linked programs for system maintenance/recovery (if being stuck in single user). But well ... I think I could suggest a good workaround for this. What about having these wrapper scripts in /etc/rc.d calling another (kind of) subscript, with the only goal to get /usr/local mounted ? Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Sunday 30 November 2003 16:54, Richard Coleman wrote:
But it doesn't help if you need a port to start earlier than something
in the base. This could happen if you've replaced sendmail with
postfix, and use maps from a remote database (openldap, postgresql,
etc). I'm sure there are other examples as well (nss_ldap, etc).
Then you can just as easily nuke the entire mailer.conf principle and symlink
bin/postfix to etc/rc.d/050.postfix.sh.
Point being: these are customized setups that require skill to get even
remotely working, so one can assume that the person installing the port can
read instructions given in pkg-message.
I don't think any ports/package system is capable of correctly setting all
*runtime* dependencies especially when it allows it's users to change
configurations after installation without recording the changes back into the
ports/pkg system.
However - to allow this flexibility, the ports system should try to respect
the installation prefix.
Nothing prevents a port from entering If you need ${PORTNAME} to start before
foo, symlink ${PREFIX}/etc/rc.d/${PORTNAME}.sh to /etc/rc.d/ and make sure
it's lexically sorted before foo into pkg-message.
Then the statement in UPDATING can read:
find /etc/rc.d \! -type l -print | xargs rm -vf
and it will always apply.
Perhaps the patch below (or something similar) should be added as well to make
people aware of the local_startup system.
My 2c.
--
Melvyn
--- bsd.port.mk.origSun Nov 30 17:22:22 2003
+++ bsd.port.mk Sun Nov 30 17:29:21 2003
@@ -766,6 +766,9 @@
#apply here. It is recommended that you use
#%%PREFIX%% for ${PREFIX}, %%LOCALBASE%% for
#${LOCALBASE} and %%X11BASE%% for ${X11BASE}.
+# INSTALLS_RCSCRIPT - If set, bsd.port.mk will check if ${LOCALBASE} is equal
+#to ${PREFIX} or else suggest that ${PREFIX}/etc/rc.d
should
+#be added to local_startup in /etc/rc.conf
# DOCSDIR - Name of the directory to install the packages docs in
#(default: ${PREFIX}/share/doc/${PORTNAME}).
# EXAMPLESDIR - Name of the directory to install the packages examples in
@@ -3127,6 +3130,10 @@
@${MKHTMLINDEX} ${PREFIX}/lib/X11/doc/html
.endif
.endif
+.endif
+.if defined(INSTALLS_RCSCRIPT) ${LOCALBASE} != ${PREFIX}
+ @${ECHO_MSG} You should verify if ${PREFIX}/etc/rc.d is in local_startup
+ @${ECHO_MSG} in /etc/rc.conf or /etc/defaults/rc.conf
.endif
.endif
pgp0.pgp
Description: signature
Re: 5.2-BETA and related ports issues
Melvyn Sopacua [EMAIL PROTECTED] writes: Then you can just as easily nuke the entire mailer.conf principle and symlink bin/postfix to etc/rc.d/050.postfix.sh. This is actually one of the two recommended ways of starting postfix (and the one I prefer). The main reason for mailer.conf to exist is that a lot of scripts have /usr/sbin/sendmail hardcoded and TPTB decided that they didn't want to use 'use.perl port'-style symlinks. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Andreas Klemm wrote: I guess I don't see the problem. What is wrong with ports adding startup scripts to /etc/rc.d? For certain ports, that is the only way to get the startup dependencies right (like making sure openldap or postgresql starts before your mail system). This will become more important as more of the base system moves to ports/packages. Just refine the note in UPDATING to specifically state which startup scripts to remove, rather than rm -rf /etc/rc.d/*. As I wrote im my previous mail we could import wrapper scripts for such basic services, since there are only few services that are so generic, that they have to be available so early in boot order. I strongly would dislike creating ports to install stuff under /etc/whatever. This would start to violate things for what I liked FreeBSD for all these many years and I hope/think other have the same feeling concerning this. Andreas /// But that kinda defeats the purpose of RCNG. One of the best features of RCNG is that it makes it easier to add/delete applications from the system. Not using it for this purpose reduces its utility. Let's not let the typical BSD traditionalism get in the way of using RCNG for what it's designed. Don't get me wrong. I'm not advocating Linux-style integration of packages/ports. But this seems fairly harmless. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Dag-Erling Smørgrav wrote: Melvyn Sopacua [EMAIL PROTECTED] writes: Then you can just as easily nuke the entire mailer.conf principle and symlink bin/postfix to etc/rc.d/050.postfix.sh. This is actually one of the two recommended ways of starting postfix (and the one I prefer). The main reason for mailer.conf to exist is that a lot of scripts have /usr/sbin/sendmail hardcoded and TPTB decided that they didn't want to use 'use.perl port'-style symlinks. DES But all these seem like such hacks. It would be so much cleaner to move sendmail.sh out of the way and just add postfix.sh to /etc/rc.d, rather than using tricks with symlinks and rc.conf variables. If you have a small number of ports added, it's not a big deal. But all these hacks get confusing when you have a lot of ports, each doing it's own special trick. The mailer.conf issue (for mail injection) is a separate issue and there's really no way around that. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Sunday 30 November 2003 23:00, Richard Coleman wrote: Dag-Erling Smørgrav wrote: Melvyn Sopacua [EMAIL PROTECTED] writes: Then you can just as easily nuke the entire mailer.conf principle and symlink bin/postfix to etc/rc.d/050.postfix.sh. This is actually one of the two recommended ways of starting postfix (and the one I prefer). The main reason for mailer.conf to exist is that a lot of scripts have /usr/sbin/sendmail hardcoded and TPTB decided that they didn't want to use 'use.perl port'-style symlinks. DES But all these seem like such hacks. It would be so much cleaner to move sendmail.sh out of the way and just add postfix.sh to /etc/rc.d, rather than using tricks with symlinks and rc.conf variables. Symlinks have the added advantage that you can easily see what you've done using ls(1) - unlike /usr/sbin/sendmail being a shell script. In this specific case, postfix already supports the 'start' and 'stop' arguments, so there's no need for a wrapper script translating arguments. If you have a small number of ports added, it's not a big deal. But all these hacks get confusing when you have a lot of ports, each doing it's own special trick. Isn't that *exactly why* ports should respect $PREFIX? At least than you know that startup scripts are in one place. Maybe all that is needed is a variable RCDIR?= etc/rc.d, for people who want to 'deviate' from this convention. The mailer.conf issue (for mail injection) is a separate issue and there's really no way around that. Just to be clear: with 'nuke' I meant sendmail_enable=NONE in /etc/rc.conf. Very convenient I might add. -- Melvyn === FreeBSD sarevok.webteckies.org 5.2-BETA FreeBSD 5.2-BETA #1: Sat Nov 29 00:15:33 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ SAREVOK_NOFW_DBG i386 === pgp0.pgp Description: signature
Re: 5.2-BETA and related ports issues
Robert Watson wrote: On Sun, 30 Nov 2003, Andreas Klemm wrote: I have a better idea, then we perhaps need something like a wrapper script that is part of the FreeBSD basic system under /etc/rc.d that checks for the start script under $LOCALBASE/etc/rc.d and starts it very early. Hmm. I talked with Gordon about this issue some last night, but he pointed out a snag: most installs of FreeBSD place /usr on a separate partition from /. The rcNG ordering decision is made before /usr is mounted, as /usr is mounted as part of the pieces kicked off by rc.d. So it would be a fairly large departure from the current implementation of the rcNG code to reevaluate the ordering once more directories were available in which to find scripts to run. Not that it's not doable, but we need to think about it carefully (and, unfortunately, it's not as easy as simply adding /usr/local/etc/rc.d to the list..) In PR conf/56736: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736 I suggested something like that: evaluate rcorder, execute till a certain point, the reevaluate and continue exection. If you are interested I can modify the patch to do just that. -Oliver ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Melvyn Sopacua wrote: Isn't that *exactly why* ports should respect $PREFIX? At least than you know that startup scripts are in one place. Maybe all that is needed is a variable RCDIR?= etc/rc.d, for people who want to 'deviate' from this convention. I like that idea. That could work. But to make this seemless (in the case of RCDIR=/etc/rc.d), we would need to start adding the RCNG keywords to the startup scripts added by ports. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Dag-Erling Smørgrav wrote: Andreas Klemm [EMAIL PROTECTED] writes: I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ That is very, very bad. I wish we had some kind of ports QA team :( Can I assign PR 56748 to [EMAIL PROTECTED] http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/56748 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
* Robert Watson [EMAIL PROTECTED] [031130 11:36]: On Sun, 30 Nov 2003, Andreas Klemm wrote: I have a better idea, then we perhaps need something like a wrapper script that is part of the FreeBSD basic system under /etc/rc.d that checks for the start script under $LOCALBASE/etc/rc.d and starts it very early. Hmm. I talked with Gordon about this issue some last night, but he pointed out a snag: most installs of FreeBSD place /usr on a separate partition from /. The rcNG ordering decision is made before /usr is mounted, as /usr is mounted as part of the pieces kicked off by rc.d. So it would be a fairly large departure from the current implementation of the rcNG code to reevaluate the ordering once more directories were available in which to find scripts to run. Not that it's not doable, but we need to think about it carefully (and, unfortunately, it's not as easy as simply adding /usr/local/etc/rc.d to the list..) Having wrapper Since this issue only comes up for a small number of ports, mostly those ports which can behave as back-end services for things that are in the base, wouldn't in be sufficient to have certain checkpoints in the rcNG code that simple scanned for and ran anything in a given location? You wouldn't need to reorder anything, simply have clearly defined pre-whatever or post-whatever steps that did something like: for i in `grep RUNAT: post-mount-usr /usr/local/etc/rc.d/*.sh` ; do [ -x $i ] sh $1; done --Mike pgp0.pgp Description: PGP signature
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Richard Coleman [EMAIL PROTECTED] writes: But that kinda defeats the purpose of RCNG. One of the best features of RCNG is that it makes it easier to add/delete applications from the system. Not using it for this purpose reduces its utility. Let's not let the typical BSD traditionalism get in the way of using RCNG for what it's designed. Don't get me wrong. I'm not advocating Linux-style integration of packages/ports. But this seems fairly harmless. Ports belong into /usr/local, not into /etc. There should be some hook that allows port start scripts to run before some base system scripts, and if Oliver's two-staged reevaluate approach supports this with / and /usr in separate partitions, then why not take his suggestion? There's nothing that prevents RCNG from stretching out its fangs to /usr/local/etc/rc*, in fact, hier(7) encourages that. If I get the picture right, what's suggested is that after mounting local file systems, the RC order is re-evaluated, and again after mounting remote file systems (diskless). This would allow the system to gradually complete its /etc/rc* picture. Another idea would be to use unionfs or something to keep /usr/local/etc/rc.d in the root partition for real, and when it's shadowed by the actual /usr/local or /usr mount, punch a hole so you can look at the rootfs with unionfs or something. I'd like Oliver's suggestion better though. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
In message: [EMAIL PROTECTED] Andreas Klemm [EMAIL PROTECTED] writes: : I have a better idea, then we perhaps need something like a : wrapper script that is part of the FreeBSD basic system under /etc/rc.d : that checks for the start script under $LOCALBASE/etc/rc.d : and starts it very early. Only if $LOCALBASE is acutally mounted, which can be a problem depending on when 'very early' is. :-( Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Matthias Andree wrote: Richard Coleman [EMAIL PROTECTED] writes: But that kinda defeats the purpose of RCNG. One of the best features of RCNG is that it makes it easier to add/delete applications from the system. Not using it for this purpose reduces its utility. Let's not let the typical BSD traditionalism get in the way of using RCNG for what it's designed. Don't get me wrong. I'm not advocating Linux-style integration of packages/ports. But this seems fairly harmless. Ports belong into /usr/local, not into /etc. There should be some hook that allows port start scripts to run before some base system scripts, and if Oliver's two-staged reevaluate approach supports this with / and /usr in separate partitions, then why not take his suggestion? There's nothing that prevents RCNG from stretching out its fangs to /usr/local/etc/rc*, in fact, hier(7) encourages that. If I get the picture right, what's suggested is that after mounting local file systems, the RC order is re-evaluated, and again after mounting remote file systems (diskless). This would allow the system to gradually complete its /etc/rc* picture. Another idea would be to use unionfs or something to keep /usr/local/etc/rc.d in the root partition for real, and when it's shadowed by the actual /usr/local or /usr mount, punch a hole so you can look at the rootfs with unionfs or something. I'd like Oliver's suggestion better though. I guess I'm not really arguing for putting the startup scripts for ports in /etc/rc.d (contradicting what I said earlier). But I do think that RCNG/rcorder needs to be extended to handle ports. And it needs to be done in a more comprehensive fashion than just adding special hooks for backend databases. The multiple rcorder evaluation method you mention sounds like a good place to start. The unionfs idea is also interesting. But I doubt many people trust it enough to use it for this purpose. It's a shame really, but that's another discussion. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Sun, 30 Nov 2003, Richard Coleman wrote: Andreas Klemm wrote: I guess I don't see the problem. What is wrong with ports adding startup scripts to /etc/rc.d? For certain ports, that is the only way to get the startup dependencies right (like making sure openldap or postgresql starts before your mail system). This will become more important as more of the base system moves to ports/packages. Just refine the note in UPDATING to specifically state which startup scripts to remove, rather than rm -rf /etc/rc.d/*. As I wrote im my previous mail we could import wrapper scripts for such basic services, since there are only few services that are so generic, that they have to be available so early in boot order. I strongly would dislike creating ports to install stuff under /etc/whatever. This would start to violate things for what I liked FreeBSD for all these many years and I hope/think other have the same feeling concerning this. Andreas /// But that kinda defeats the purpose of RCNG. One of the best features of RCNG is that it makes it easier to add/delete applications from the system. Not using it for this purpose reduces its utility. Let's not let the typical BSD traditionalism get in the way of using RCNG for what it's designed. Don't get me wrong. I'm not advocating Linux-style integration of packages/ports. But this seems fairly harmless. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] Perhaps we just need to place wrapper startup script, that will try to start real startup script in /usr/local/etc/rc.d if it exist? Most of ports are installed into /usr/local, so, lets don't use hierarchy above that. Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Mon, 1 Dec 2003, Maxim M. Kazachek wrote: On Sun, 30 Nov 2003, Richard Coleman wrote: snip For 5.2-RELEASE, I think we should ignore the whole issue and let the couple of ports that insert things in /etc/rc.d just do it. We're not going to find any other solution in time to either close the discussion or test it properly. For 5.2-CURRENT, I think we should revisit this issue with one of the following conclusions winning out, and the rest being discarded as flame-bait: (1) Combine / and /usr into a single file system by default, and add /usr/local/etc/rc.d to the search order, with appropriate hacks to handle old-style scripts. The devil will be in the bikeshed, but the implementation is easy, except for the bit where we explain that NFS-mounted /usr/local won't work too well. (2) Reevaluate the order at routine points in the boot where new scripts might now be available (due to file system mounts or whatever). Essentially insert the new cards into the deck, and shuffle. This requires rethinking of our current approach, which assumes a static order is created once at the start of the boot by rcorder(8). The devil will be in the big picture *and* the details of the implementation. (3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a new directory that third party applications are allowed to modify during install, and that will be present for the creation of the static ordering by rcorder(8) early in the boot. The devil will be in the bikeshed, but the implementation is easy. (4) Continue to ignore the issue and let some ports install into /etc/rc.d and consider them unorthodox, incorrect, but something we can overlook. The devil isn't here, or at least, if it is, we'll overlook it. I'm actually leaning towards (2) as being the best solution, as it's easy and functional. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Sun, Nov 30, 2003 at 11:47:24PM -0500, Robert Watson wrote: On Mon, 1 Dec 2003, Maxim M. Kazachek wrote: On Sun, 30 Nov 2003, Richard Coleman wrote: ..snip.. For 5.2-CURRENT, I think we should revisit this issue with one of the following conclusions winning out, and the rest being discarded as flame-bait: (1) Combine / and /usr into a single file system by default, and add /usr/local/etc/rc.d to the search order, with appropriate hacks to handle old-style scripts. The devil will be in the bikeshed, but the implementation is easy, except for the bit where we explain that NFS-mounted /usr/local won't work too well. I would like to show support for this option. I've been running /usr on the / partition on *all* my FBSD machines for the past 4 years. The reasons for having a separate / and /usr just don't apply today. Disks are large enough to hold both, and UFS(FFS) is stable. Sun and SGI both combine / and /usr on their pre-installed workstation machines. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
David O'Brien wrote: For 5.2-CURRENT, I think we should revisit this issue with one of the following conclusions winning out, and the rest being discarded as flame-bait: (1) Combine / and /usr into a single file system by default, and add /usr/local/etc/rc.d to the search order, with appropriate hacks to handle old-style scripts. The devil will be in the bikeshed, but the implementation is easy, except for the bit where we explain that NFS-mounted /usr/local won't work too well. I would like to show support for this option. I've been running /usr on the / partition on *all* my FBSD machines for the past 4 years. The reasons for having a separate / and /usr just don't apply today. Disks are large enough to hold both, and UFS(FFS) is stable. Sun and SGI both combine / and /usr on their pre-installed workstation machines. That abandons the ability to have a read-only /usr. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Robert Watson wrote: For 5.2-CURRENT, I think we should revisit this issue with one of the following conclusions winning out, and the rest being discarded as flame-bait: (1) Combine / and /usr into a single file system by default, and add /usr/local/etc/rc.d to the search order, with appropriate hacks to handle old-style scripts. The devil will be in the bikeshed, but the implementation is easy, except for the bit where we explain that NFS-mounted /usr/local won't work too well. (2) Reevaluate the order at routine points in the boot where new scripts might now be available (due to file system mounts or whatever). Essentially insert the new cards into the deck, and shuffle. This requires rethinking of our current approach, which assumes a static order is created once at the start of the boot by rcorder(8). The devil will be in the big picture *and* the details of the implementation. (3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a new directory that third party applications are allowed to modify during install, and that will be present for the creation of the static ordering by rcorder(8) early in the boot. The devil will be in the bikeshed, but the implementation is easy. (4) Continue to ignore the issue and let some ports install into /etc/rc.d and consider them unorthodox, incorrect, but something we can overlook. The devil isn't here, or at least, if it is, we'll overlook it. I'm actually leaning towards (2) as being the best solution, as it's easy and functional. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research I think this message sums up the options quite nicely. I like option 2 the best, with option 3 a close second. I think either would be an acceptable compromise. Option 1 abandons the ability for read-only /usr, which many people like. That and the NFS problems that Robert mentioned should rule this out. But I like anything over doing nothing (option 4). Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Mon, 1 Dec 2003, Richard Coleman wrote: (2) Reevaluate the order at routine points in the boot where new scripts might now be available (due to file system mounts or whatever). Essentially insert the new cards into the deck, and shuffle. This requires rethinking of our current approach, which assumes a static order is created once at the start of the boot by rcorder(8). The devil will be in the big picture *and* the details of the implementation. (3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a new directory that third party applications are allowed to modify during install, and that will be present for the creation of the static ordering by rcorder(8) early in the boot. The devil will be in the bikeshed, but the implementation is easy. ... I'm actually leaning towards (2) as being the best solution, as it's easy and functional. I think this message sums up the options quite nicely. I like option 2 the best, with option 3 a close second. I think either would be an acceptable compromise. Option 1 abandons the ability for read-only /usr, which many people like. That and the NFS problems that Robert mentioned should rule this out. But I like anything over doing nothing (option 4). Having written the e-mail, I should really have indicated that either (2) or (3) is a winner, and (3) is probably easier. Comes of spending a lot of time on the description of the solutions, and little time on the opinion :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Fri, Nov 28, 2003 at 05:04:14PM +0100, Christian Laursen wrote: 20030829: The following rc.d scripts have been removed and should be deleted from your installation: atm2.sh atm3.sh devdb localdaemons network1 network2 network3. Depending on when you last updated world and used mergemaster(8) you may or may not have problems during the rc boot sequence. The simplest solution is an 'rm -rf /etc/rc.d/*' and then 'mergemaster -i'. The atm2.sh atm3.sh and devdb scripts were removed some time ago, so depending on when you installed -CURRENT these scripts may or may not exist on your system. I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ Cc'd to port maintainer to sanitize this All openldapXX-server ports do this for example [EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN* [...] openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slapd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@cwd /etc/rc.d Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Andreas Klemm [EMAIL PROTECTED] writes: I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ That is very, very bad. I wish we had some kind of ports QA team :( DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Smørgrav wrote: Andreas Klemm [EMAIL PROTECTED] writes: I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ That is very, very bad. I wish we had some kind of ports QA team :( Maybe we should flag this port immediately as BROKEN. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Andreas Klemm wrote: The following rc.d scripts have been removed and should be deleted from your installation: atm2.sh atm3.sh devdb localdaemons network1 network2 network3. Depending on when you last updated world and used mergemaster(8) you may or may not have problems during the rc boot sequence. The simplest solution is an 'rm -rf /etc/rc.d/*' and then 'mergemaster -i'. The atm2.sh atm3.sh and devdb scripts were removed some time ago, so depending on when you installed -CURRENT these scripts may or may not exist on your system. I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ Cc'd to port maintainer to sanitize this All openldapXX-server ports do this for example [EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN* [...] openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slapd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@cwd /etc/rc.d It's too bad that portlint doesn't catch this. I wonder how hard it would be to add such detection. It already does some pretty amazing stuff already. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Sm?rgrav wrote: Andreas Klemm [EMAIL PROTECTED] writes: I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ That is very, very bad. I wish we had some kind of ports QA team :( Well, er, a number of us do essentially nothing BUT ports QA. Kris pgp0.pgp Description: PGP signature
Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Sat, Nov 29, 2003 at 03:25:08PM +0100, Andreas Klemm wrote: All openldapXX-server ports do this for example [EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN* [...] openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slapd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@cwd /etc/rc.d That should be fixed before the release. I can't think of any reason why these should be using /etc/rc.d instead of /usr/local/etc/rc.d. Kris pgp0.pgp Description: PGP signature
Re: 5.2-BETA and related ports issues
Kris Kennaway [EMAIL PROTECTED] writes: On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Sm?rgrav wrote: That is very, very bad. I wish we had some kind of ports QA team :( Well, er, a number of us do essentially nothing BUT ports QA. Do you actually review ports Makefiles? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Sat, Nov 29, 2003 at 11:38:53PM +0100, Dag-Erling Sm?rgrav wrote: Kris Kennaway [EMAIL PROTECTED] writes: On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Sm?rgrav wrote: That is very, very bad. I wish we had some kind of ports QA team :( Well, er, a number of us do essentially nothing BUT ports QA. Do you actually review ports Makefiles? Not pre-review, but post-review, certainly. We also have an cluster of ~25 machines and a number of ports committers who spend their days detecting and fixing problems with the ports collection. Kris pgp0.pgp Description: PGP signature
Re: 5.2-BETA and related ports issues
Kris Kennaway [EMAIL PROTECTED] writes: On Sat, Nov 29, 2003 at 11:38:53PM +0100, Dag-Erling Sm?rgrav wrote: Do you actually review ports Makefiles? Not pre-review, but post-review, certainly. We also have an cluster of ~25 machines and a number of ports committers who spend their days detecting and fixing problems with the ports collection. Well, in that case I'll ammend my comment to I wish our ports QA team had more time and resources :) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Sat, 29 Nov 2003, Dag-Erling Smørgrav wrote: Do you actually review ports Makefiles? You _are_ kidding here, right? Yes, the ports team does read over the ports Makefile. Yes, the bento cluster attempts to find all the problems that can be found by automated processes. Yes, my own code attempts to lint inconsistencies in the ports collection. Yes, other automated scripts attempt to continually build /usr/ports/INDEX looking for inconsistencies, and maintainers whose email address bounces, and maintainers who might not have seen PRs about their ports (maintainers who are not committers, in this case). Yes,Bill Fenner's script attempts to find all unfetchable ports. I've seen other scripts that attempt to portlint the entire ports hierarchy but I don't know if they run periodically. They probably ought to. There are currently, as of this moment, 9722 ports in the tree. It's not humanly possible to read over every line of every single Makefile plus every single pkg-plist and grok them all. The ports folks rely on many eyes for help with this, just as with every other line of code in FreeBSD. There are certainly a lot of bugs in the ports tree. If people use send-pr for its intended purpose, specific bugs are more likely to get fixed than by casual discussions on mailing lists. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Kris Kennaway wrote: On Sat, Nov 29, 2003 at 03:25:08PM +0100, Andreas Klemm wrote: All openldapXX-server ports do this for example [EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN* [...] openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slapd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@cwd /etc/rc.d That should be fixed before the release. I can't think of any reason why these should be using /etc/rc.d instead of /usr/local/etc/rc.d. Sorry that I missed that thread, our ISP has f*cked up our connection. The reason I did this was to support services like mail and nss_ldap. I really like to be prefix safe, PR conf/56736 relates to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736 I agree that there should be a better solution, and already asked Mike Makonnen [EMAIL PROTECTED] about it, but nobody seemed to care. IMHO not participating in rcorder(8) makes the packing list pettier and avoids an ugly hack, which is good, but restrains functionality. I like the idea of account managed in an centralized LDAP directory very much. So, do you still think the scripts should not participate in rcorder(8)? It's easy to change the ports, but this is probably not the right fix. -Oliver ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Kris Kennaway wrote: On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Smorgrav wrote: Andreas Klemm [EMAIL PROTECTED] writes: I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ That is very, very bad. I wish we had some kind of ports QA team :( Well, er, a number of us do essentially nothing BUT ports QA. I'm sorry if I did something disturbing, and I'm surely interested in ports tree QA! I know that I violate the prefix, and did that on purpose, see my comment in net/opendldap2[012]-server/Makefile: # currently the only way to participate in rcorder(8) I posted PR conf/56736: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736 but nobody seemed to care, and I had enough construction areas that I didn't wanted to start a discussion about that. The point is that we might want to have some port services to start early. That gives the possibility to move functionality from the base system to ports, which I believe isn't bad. I can simply change the openldap ports so that they are nice and quiet, but IMHO that does not really solve a problem. But please correct me if my arguments are too simple-minded. -Oliver ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Mark Linimon wrote: On Sat, 29 Nov 2003, Dag-Erling Smørgrav wrote: Do you actually review ports Makefiles? You _are_ kidding here, right? Yes, the ports team does read over the ports Makefile. Yes, the bento cluster attempts to find all the problems that can be found by automated processes. Yes, my own code attempts to lint inconsistencies in the ports collection. Yes, other automated scripts attempt to continually build /usr/ports/INDEX looking for inconsistencies, and maintainers whose email address bounces, and maintainers who might not have seen PRs about their ports (maintainers who are not committers, in this case). Yes,Bill Fenner's script attempts to find all unfetchable ports. I've seen other scripts that attempt to portlint the entire ports hierarchy but I don't know if they run periodically. They probably ought to. There are currently, as of this moment, 9722 ports in the tree. It's not humanly possible to read over every line of every single Makefile plus every single pkg-plist and grok them all. The ports folks rely on many eyes for help with this, just as with every other line of code in FreeBSD. There are certainly a lot of bugs in the ports tree. If people use send-pr for its intended purpose, specific bugs are more likely to get fixed than by casual discussions on mailing lists. Please: I *know* that I violate the prefix. We don't need more QA people here (we do, but thats not the point in this discussuion), we need more people with which you can discuss open questions. Apperantly nobody cared about PR conf/56736 nor PR bin/56748, and I didn't had the capacity to push them. I guess I'll back out the installation into /etc, but hey, how do I have to yell feature needed? Please don't blame ports QA. Blame a misguided porter that didn't get support from the base system maintainers... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Michael L. Squires [EMAIL PROTECTED] writes: On both systems I'm running postgreSQL7 from ports. In both cases the pgctl (the startup script) is called twice, and obviously it fails the second time. It is called both by /etc/rc.d/localdaemons and by /etc/rc.d/localpkg. I haven't looked any deeper than that, yet. On the portable the IP number, netmask, and router address are set in /etc/rc.conf. Both /etc/rc.d/netoptions and /etc/rc.d/network3 appear to be execuring (I see 'Additional TCP options: twice) and one of them is trying to reset the router address set by rc.conf, resulting in an error. There is an item in UPGRADING that explains this: 20030829: The following rc.d scripts have been removed and should be deleted from your installation: atm2.sh atm3.sh devdb localdaemons network1 network2 network3. Depending on when you last updated world and used mergemaster(8) you may or may not have problems during the rc boot sequence. The simplest solution is an 'rm -rf /etc/rc.d/*' and then 'mergemaster -i'. The atm2.sh atm3.sh and devdb scripts were removed some time ago, so depending on when you installed -CURRENT these scripts may or may not exist on your system. -- Best regards Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Fri, Nov 28, 2003 at 10:53:29AM -0500, Michael L. Squires wrote: On both systems I'm running postgreSQL7 from ports. In both cases the pgctl (the startup script) is called twice, and obviously it fails the second time. It is called both by /etc/rc.d/localdaemons and by /etc/rc.d/localpkg. [snip] Both /etc/rc.d/netoptions and /etc/rc.d/network3 appear to be execuring (I see 'Additional TCP options: twice) I can't comment on the other stuff, but both these problems are because of the `20030829' entry in /usr/src/UPDATING. ATB, james ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
