Re: ports modifying system setups
Gergely CZUCZY wrote: On Wed, Nov 21, 2007 at 11:43:35PM -0800, Doug Barton wrote: Gergely CZUCZY wrote: echo 'sevice_enable="YES"' >> /etc/rc.conf.local Yes, I think we all know how to go about this manually. The question at hand is whether or not it's possible or desirable to create the possibility of doing it for the user at port install time. If what you're trying to say here is that you don't find such a facility interesting or necessary, thanks for stating your opinion. I said, that this can be done from the Makefile as well, if that OPTIONS of yours is enabled. Seeing as I was gone (really way gone) from the FreeBSD community for a while, but I used to be very closely associated, I felt that it was possible that because I had seen both environments (several other unixes, like Solaris and different Linuxes) and FreeBSD, that before I stopped seeing things as novel, I might be able to point out some differences that might be useful. I've seen a lot of knee-jerk responses to anything new; this group isn't the largest, but they ARE the loudest. I'm not sayiing I'm right, but I AM saying that it's worth some serious consideration. I'm suggesting a number of ideas that just might be worth adding. In this case, what I meant was to change the rules, the commonly accepted methods, for ports to install daemons, to that they directly patch an rc file, not to make some change in bsd.port.mk, but it really wouldn't be all that hard to code up some macro to do this, so perhaps the idea is sound. I'm currenlty going to present something regarding adding a ports screening method, but that's a much harder thing to code. This macro handler, that would be comparatively easy. I see that we need to decide whether to do it or not, but that decision can wait until I have a macro, a diff to gbsd.port.mk coded up, so we don't discuss this twice (you can kill the idea very well then, you['re not going to lose the opportunity). The only things I see to decide NOW are: 1) name of this proposed macro. I like INSTALL_DAEMON_NAME, do you? 2) the name of the file to carry the resulting definitions. It could be /etc/rc.local, I saw that suggested, but I would like to say why I like $(PREFIX)/local/etc/rc.d. I would rather that the dividing line between any and all system stuff and ports stuff be very very firm and clear. I detest the Linux habit of folding /usr/bin and /usr/local/bin together, and I would really want to maintain FreeBSD's current stance on this. Next couple days, I will show you folks a diff about this. We can make the changes on the two items above rather easily then, but you might want to post your feelings now on it. Save the argument over the entire notion until I get a diff ready. I mean, that's the FreeBSD way, that no one gets any sort of prior blanket approval, and I wouldn't change it for the world. Sincerely, Gergely Czuczy mailto: [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
On Wed, 21 Nov 2007 22:48:59 -0800 Doug Barton <[EMAIL PROTECTED]> wrote: > RW wrote: > > On Wed, 21 Nov 2007 12:14:17 -0800 > > Doug Barton <[EMAIL PROTECTED]> wrote: > > > >> ... I have for some time wanted to add > >> support to rc.subr for a /usr/local/etc/rc.conf.d so that ports > >> could install sensible defaults for rc.conf, > > > > What's the advantage of doing that over having the the defaults > > in the rc.d script, > > I thought I explained that. The point of this thread was that services > installed by ports are not (any longer?) on by default. What I'm > proposing is a way to allow the user to choose to enable the service > using an OPTION (amongst other things). You wrote defaults (plural), I thought you might want to handle other thing apart from yes/no. Having the port options determine whether a port should be off or on by default sounds like a nightmare. You wouldn't know what the packager or previous administrator had set as the default without checking the files. People would still end-up putting settings in rc.conf just to be sure - except that then you wouldn't be able to rely on a comment to turn something off. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
On Thu, 22 Nov 2007, Gergely CZUCZY wrote: Gergely CZUCZY wrote: echo 'sevice_enable="YES"' >> /etc/rc.conf.local I said, that this can be done from the Makefile as well, if that OPTIONS of yours is enabled. But that would violate the principle that ports shouldn't touch files in /etc. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
On Thu, Nov 22, 2007 at 12:43:50AM -0800, Doug Barton wrote: > On Thu, 22 Nov 2007, Gergely CZUCZY wrote: > > >>Gergely CZUCZY wrote: > >> > >>>echo 'sevice_enable="YES"' >> /etc/rc.conf.local > > >I said, that this can be done from the Makefile as well, if that OPTIONS > >of yours is enabled. > > But that would violate the principle that ports shouldn't touch files in /etc. from rc.conf(5): first: The file /etc/rc.conf.local is used to override settings in /etc/rc.conf for historical reasons. See the rc_conf_files variable below. second: rc_conf_files (str) This option is used to specify a list of files that will override the settings in /etc/defaults/rc.conf. The files will be read in the order in which they are specified and should include the full path to the file. By default, the files specified are /etc/rc.conf and /etc/rc.conf.local So, extend rc_conf_files with /usr/local/etc/rc.conf, that's an acceptable extension IMO, and you're done. ports can touch that. Though, IMO ports could touch the .local files, regardless it's in /etc/. That's why it's rc.conf_.local_ . Anyways, I'm not a core member, it was just a point of view. Sincerely, Gergely Czuczy mailto: [EMAIL PROTECTED] -- Weenies test. Geniuses solve problems that arise. pgp5bW7Rj7e6k.pgp Description: PGP signature
Re: ports modifying system setups
On Wed, Nov 21, 2007 at 11:43:35PM -0800, Doug Barton wrote: > Gergely CZUCZY wrote: > > > echo 'sevice_enable="YES"' >> /etc/rc.conf.local > > Yes, I think we all know how to go about this manually. The question > at hand is whether or not it's possible or desirable to create the > possibility of doing it for the user at port install time. > > If what you're trying to say here is that you don't find such a > facility interesting or necessary, thanks for stating your opinion. I said, that this can be done from the Makefile as well, if that OPTIONS of yours is enabled. Sincerely, Gergely Czuczy mailto: [EMAIL PROTECTED] -- Weenies test. Geniuses solve problems that arise. pgpzKVaQ9eqzE.pgp Description: PGP signature
Re: ports modifying system setups
Gergely CZUCZY wrote: > echo 'sevice_enable="YES"' >> /etc/rc.conf.local Yes, I think we all know how to go about this manually. The question at hand is whether or not it's possible or desirable to create the possibility of doing it for the user at port install time. If what you're trying to say here is that you don't find such a facility interesting or necessary, thanks for stating your opinion. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
On Wed, Nov 21, 2007 at 10:48:59PM -0800, Doug Barton wrote: > RW wrote: > > On Wed, 21 Nov 2007 12:14:17 -0800 > > Doug Barton <[EMAIL PROTECTED]> wrote: > > > >> ... I have for some time wanted to add support > >> to rc.subr for a /usr/local/etc/rc.conf.d so that ports could install > >> sensible defaults for rc.conf, > > > > What's the advantage of doing that over having the the defaults > > in the rc.d script, > > I thought I explained that. The point of this thread was that services > installed by ports are not (any longer?) on by default. What I'm > proposing is a way to allow the user to choose to enable the service > using an OPTION (amongst other things). echo 'sevice_enable="YES"' >> /etc/rc.conf.local done. Sincerely, Gergely Czuczy mailto: [EMAIL PROTECTED] -- Weenies test. Geniuses solve problems that arise. pgpcL3LDCaOHo.pgp Description: PGP signature
Re: ports modifying system setups
RW wrote: > On Wed, 21 Nov 2007 12:14:17 -0800 > Doug Barton <[EMAIL PROTECTED]> wrote: > >> ... I have for some time wanted to add support >> to rc.subr for a /usr/local/etc/rc.conf.d so that ports could install >> sensible defaults for rc.conf, > > What's the advantage of doing that over having the the defaults > in the rc.d script, I thought I explained that. The point of this thread was that services installed by ports are not (any longer?) on by default. What I'm proposing is a way to allow the user to choose to enable the service using an OPTION (amongst other things). Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
On Wed, 21 Nov 2007 12:14:17 -0800 Doug Barton <[EMAIL PROTECTED]> wrote: > > ... I have for some time wanted to add support > to rc.subr for a /usr/local/etc/rc.conf.d so that ports could install > sensible defaults for rc.conf, What's the advantage of doing that over having the the defaults in the rc.d script, which is generally what happens now for scripts installed by ports. It would allow a port to install variant defaults, but that sounds very confusing. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
Scot Hetzel wrote: >> On Sun, Nov 18, 2007 at 08:17:36PM -0500, Chuck Robey wrote: >>> activate the port, and if so, the port would add a line of the form >>> 'portname_enable="YES"', and this would make your new port operate. >>> Well, it seems from what I see of my new system, that this is no longer >>> the case. I could understand (and approve of) ports not being allowed >>> to modify any /etc/contents, but howcome ports can't use this rather >>> obvious workaround? > Edwin is correct that ports never had this behavior when they were > converted to the rc_ng startup script style, It's not "next generation" anymore, can we refer to it as rc.d instead please? :) As for Chuck's suggestion, I have for some time wanted to add support to rc.subr for a /usr/local/etc/rc.conf.d so that ports could install sensible defaults for rc.conf, and delete them when they are deinstalled. There was some objection to this idea on the freebsd-rc list when I suggested it though so I haven't pursued it. (I don't remember off hand what the objection was.) My idea is pretty simple, rc.subr already has support for /etc/rc.conf.d which allows for files with the same name as the name= attribute in the rc.d script to specify the settings for that service. I'd like to expand this to a local version that ports could write to on install. I think it would also be good to add an OPTION for "start on boot," which the user can enable before the _enable option is actually set to yes by the port. We can flesh this out in more detail if people are interested. Doug -- This .signature sanitized for your protection. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
Naram Qashat wrote:
In the pkgtools.conf file that portupgrade installs, there's two
sections, BEFOREINSTALL and AFTERINSTALL. In BEFOREINSTALL, you could
put the following in to make it try to stop the service if there's an rc
script for the port:
'*' => proc { |origin| cmd_stop_rc(origin) }
And almost the same thing for AFTERINSTALL, except cmd_start_rc instead
of cmd_stop_rc. And as long as the line for that service is in
/etc/rc.conf, it'll start or stop via the rc script. It even says that
in the comments of pkgtools.conf.
Ah, you misunderstood me. I was never saying, or meaning, that ports
could not do it, I was saying they did not do it, no one I have seen
implemented that behavior. Yes, you're certainly right, they can,
they've had the ability all along.
Naram Qashat
Chuck Robey wrote:
Naram Qashat wrote:
Also a good thing to point out is that portupgrade can be configured
to automatically start or stop a port's daemon via it's
/usr/local/etc/rc.d script, which still relies on having the
appropriate line in /etc/rc.conf to tell the rc.d script to run, but
it is helpful for upgrading ports which have daemons so they can be
shut down and then started again after the upgrade is complete.
Not sure I understand what you mean here. I *think* I remember that
ports (quoite a while back) did not require any patching of rc.conf at
all, just coding in /usr/local/etc/rc.d. Nowadays, there are required
lines in rc.conf which fire sections of rc.d, but apparently (and i do
approve of this) the /etc/rc.conf can't be touched. I guess I don't
understand why not have the entire startup code in rc.d, and merely
have rc source in rc.d after it's finished with rc.conf.
I just took a good long look at portupgrade, I didn't see any option
like you're talking about. You understand, there is no reason that
ports couldn't do what I'm asking about. They aren't written to do
this (at least, several different daemon-ports that I've installed
all required manual patching of rc.conf). This isn't just my own
interpretation, because the ports themselves hint to the user that
they should patch rc.conf to get the port working as a daemon.
I'm just saying that ports should be written to handle this
themselves, and not to require manual patching to get this done. One
reason would be users (non-technical ones) who install a particular
port as a dependency, and thus never even see the comments about what
they should do to get things working. I can't see any reason NOT to
do this, and good reason why it should be done.
Naram Qashat
Chuck Robey wrote:
I was wondering why ports apparently aren't allowed an obvious
freedom, that of being able to set themselves to run as daemons. A
greate long time past, I seem to remember that there used to be a
file /usr/local/etc/rc.local, which (if it existed) would be
automatically sourced in at the end of rc.conf. Ports which built
daemons were allowed (well, actually, expected) to ask the user if
they wished to activate the port, and if so, the port would add a
line of the form 'portname_enable="YES"', and this would make your
new port operate. Well, it seems from what I see of my new system,
that this is no longer the case. I could understand (and approve
of) ports not being allowed to modify any /etc/contents, but howcome
ports can't use this rather obvious workaround?
I'm pretty sure this used to be allowed... and it seems like a good
policy to me, from the number of non-technical folks who now run
FreeBSD. I just wanted to know why its not anymore.
__
_
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
Scot Hetzel wrote:
On 11/18/07, Edwin Groothuis <[EMAIL PROTECTED]> wrote:
On Sun, Nov 18, 2007 at 08:17:36PM -0500, Chuck Robey wrote:
activate the port, and if so, the port would add a line of the form
'portname_enable="YES"', and this would make your new port operate.
Well, it seems from what I see of my new system, that this is no longer
the case. I could understand (and approve of) ports not being allowed
to modify any /etc/contents, but howcome ports can't use this rather
obvious workaround?
I don't recall this behavior at all, I think you're confused with
the messages which ports print at the end of the install-phase which
say "Add 'foo_enable="YES"'" to your /etc/rc.conf to enable this
port.
Edwin is correct that ports never had this behavior when they were
converted to the rc_ng startup script style, they always required the
system administrator to set the appropriate rc variable in
/etc/rc.conf.
I remember the behavior, but not sure how far back it was. I was using
FreeBSD before rc_ng, so it could have been a _long_ time back.
Before rc_ng some scripts would automatically start on a reboot, while
others required copying the *.sh{-dist,-default,...} startup script to
one without the extentsion, as well as setting the execute bit.
This is probably what you are remembering.
Scot
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
Edwin Groothuis wrote: On Sun, Nov 18, 2007 at 08:17:36PM -0500, Chuck Robey wrote: activate the port, and if so, the port would add a line of the form 'portname_enable="YES"', and this would make your new port operate. Well, it seems from what I see of my new system, that this is no longer the case. I could understand (and approve of) ports not being allowed to modify any /etc/contents, but howcome ports can't use this rather obvious workaround? I don't recall this behaviour at all, I think you're confused with the messages which ports print at the end of the install-phase which say "Add 'foo_enable="YES"'" to your /etc/rc.conf to enable this port. Edwin Hmm. I remember this behavioour, but I can't find any example of it now. I need to go look up into my old cdroms (they're around here somewheres, I just need to go unearth them, way back to 1.0). Until I can prove this, I guess I will withdraw it, but I do remember this behavior. Ports, a long time back, used to do all the install steps that they reasonably could do. Couldn't do all the setups for things like dovecot, which has too many options, but even there, an attempt was made to change the conf file to something closer to a FreeBSD standard. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
In the pkgtools.conf file that portupgrade installs, there's two sections,
BEFOREINSTALL and AFTERINSTALL. In BEFOREINSTALL, you could put the following
in to make it try to stop the service if there's an rc script for the port:
'*' => proc { |origin| cmd_stop_rc(origin) }
And almost the same thing for AFTERINSTALL, except cmd_start_rc instead of
cmd_stop_rc. And as long as the line for that service is in /etc/rc.conf, it'll
start or stop via the rc script. It even says that in the comments of
pkgtools.conf.
Naram Qashat
Chuck Robey wrote:
Naram Qashat wrote:
Also a good thing to point out is that portupgrade can be configured
to automatically start or stop a port's daemon via it's
/usr/local/etc/rc.d script, which still relies on having the
appropriate line in /etc/rc.conf to tell the rc.d script to run, but
it is helpful for upgrading ports which have daemons so they can be
shut down and then started again after the upgrade is complete.
Not sure I understand what you mean here. I *think* I remember that
ports (quoite a while back) did not require any patching of rc.conf at
all, just coding in /usr/local/etc/rc.d. Nowadays, there are required
lines in rc.conf which fire sections of rc.d, but apparently (and i do
approve of this) the /etc/rc.conf can't be touched. I guess I don't
understand why not have the entire startup code in rc.d, and merely have
rc source in rc.d after it's finished with rc.conf.
I just took a good long look at portupgrade, I didn't see any option
like you're talking about. You understand, there is no reason that
ports couldn't do what I'm asking about. They aren't written to do this
(at least, several different daemon-ports that I've installed all
required manual patching of rc.conf). This isn't just my own
interpretation, because the ports themselves hint to the user that they
should patch rc.conf to get the port working as a daemon.
I'm just saying that ports should be written to handle this themselves,
and not to require manual patching to get this done. One reason would
be users (non-technical ones) who install a particular port as a
dependency, and thus never even see the comments about what they should
do to get things working. I can't see any reason NOT to do this, and
good reason why it should be done.
Naram Qashat
Chuck Robey wrote:
I was wondering why ports apparently aren't allowed an obvious
freedom, that of being able to set themselves to run as daemons. A
greate long time past, I seem to remember that there used to be a
file /usr/local/etc/rc.local, which (if it existed) would be
automatically sourced in at the end of rc.conf. Ports which built
daemons were allowed (well, actually, expected) to ask the user if
they wished to activate the port, and if so, the port would add a
line of the form 'portname_enable="YES"', and this would make your
new port operate. Well, it seems from what I see of my new system,
that this is no longer the case. I could understand (and approve of)
ports not being allowed to modify any /etc/contents, but howcome
ports can't use this rather obvious workaround?
I'm pretty sure this used to be allowed... and it seems like a good
policy to me, from the number of non-technical folks who now run
FreeBSD. I just wanted to know why its not anymore.
__
_
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
Naram Qashat wrote: Also a good thing to point out is that portupgrade can be configured to automatically start or stop a port's daemon via it's /usr/local/etc/rc.d script, which still relies on having the appropriate line in /etc/rc.conf to tell the rc.d script to run, but it is helpful for upgrading ports which have daemons so they can be shut down and then started again after the upgrade is complete. Not sure I understand what you mean here. I *think* I remember that ports (quoite a while back) did not require any patching of rc.conf at all, just coding in /usr/local/etc/rc.d. Nowadays, there are required lines in rc.conf which fire sections of rc.d, but apparently (and i do approve of this) the /etc/rc.conf can't be touched. I guess I don't understand why not have the entire startup code in rc.d, and merely have rc source in rc.d after it's finished with rc.conf. I just took a good long look at portupgrade, I didn't see any option like you're talking about. You understand, there is no reason that ports couldn't do what I'm asking about. They aren't written to do this (at least, several different daemon-ports that I've installed all required manual patching of rc.conf). This isn't just my own interpretation, because the ports themselves hint to the user that they should patch rc.conf to get the port working as a daemon. I'm just saying that ports should be written to handle this themselves, and not to require manual patching to get this done. One reason would be users (non-technical ones) who install a particular port as a dependency, and thus never even see the comments about what they should do to get things working. I can't see any reason NOT to do this, and good reason why it should be done. Naram Qashat Chuck Robey wrote: I was wondering why ports apparently aren't allowed an obvious freedom, that of being able to set themselves to run as daemons. A greate long time past, I seem to remember that there used to be a file /usr/local/etc/rc.local, which (if it existed) would be automatically sourced in at the end of rc.conf. Ports which built daemons were allowed (well, actually, expected) to ask the user if they wished to activate the port, and if so, the port would add a line of the form 'portname_enable="YES"', and this would make your new port operate. Well, it seems from what I see of my new system, that this is no longer the case. I could understand (and approve of) ports not being allowed to modify any /etc/contents, but howcome ports can't use this rather obvious workaround? I'm pretty sure this used to be allowed... and it seems like a good policy to me, from the number of non-technical folks who now run FreeBSD. I just wanted to know why its not anymore. __ _ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
On 11/18/07, Edwin Groothuis <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 18, 2007 at 08:17:36PM -0500, Chuck Robey wrote:
> > activate the port, and if so, the port would add a line of the form
> > 'portname_enable="YES"', and this would make your new port operate.
> > Well, it seems from what I see of my new system, that this is no longer
> > the case. I could understand (and approve of) ports not being allowed
> > to modify any /etc/contents, but howcome ports can't use this rather
> > obvious workaround?
>
> I don't recall this behavior at all, I think you're confused with
> the messages which ports print at the end of the install-phase which
> say "Add 'foo_enable="YES"'" to your /etc/rc.conf to enable this
> port.
>
Edwin is correct that ports never had this behavior when they were
converted to the rc_ng startup script style, they always required the
system administrator to set the appropriate rc variable in
/etc/rc.conf.
Before rc_ng some scripts would automatically start on a reboot, while
others required copying the *.sh{-dist,-default,...} startup script to
one without the extentsion, as well as setting the execute bit.
This is probably what you are remembering.
Scot
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
Also a good thing to point out is that portupgrade can be configured to automatically start or stop a port's daemon via it's /usr/local/etc/rc.d script, which still relies on having the appropriate line in /etc/rc.conf to tell the rc.d script to run, but it is helpful for upgrading ports which have daemons so they can be shut down and then started again after the upgrade is complete. Naram Qashat Chuck Robey wrote: I was wondering why ports apparently aren't allowed an obvious freedom, that of being able to set themselves to run as daemons. A greate long time past, I seem to remember that there used to be a file /usr/local/etc/rc.local, which (if it existed) would be automatically sourced in at the end of rc.conf. Ports which built daemons were allowed (well, actually, expected) to ask the user if they wished to activate the port, and if so, the port would add a line of the form 'portname_enable="YES"', and this would make your new port operate. Well, it seems from what I see of my new system, that this is no longer the case. I could understand (and approve of) ports not being allowed to modify any /etc/contents, but howcome ports can't use this rather obvious workaround? I'm pretty sure this used to be allowed... and it seems like a good policy to me, from the number of non-technical folks who now run FreeBSD. I just wanted to know why its not anymore. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports modifying system setups
On Sun, Nov 18, 2007 at 08:17:36PM -0500, Chuck Robey wrote: > activate the port, and if so, the port would add a line of the form > 'portname_enable="YES"', and this would make your new port operate. > Well, it seems from what I see of my new system, that this is no longer > the case. I could understand (and approve of) ports not being allowed > to modify any /etc/contents, but howcome ports can't use this rather > obvious workaround? I don't recall this behaviour at all, I think you're confused with the messages which ports print at the end of the install-phase which say "Add 'foo_enable="YES"'" to your /etc/rc.conf to enable this port. Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ports modifying system setups
I was wondering why ports apparently aren't allowed an obvious freedom, that of being able to set themselves to run as daemons. A greate long time past, I seem to remember that there used to be a file /usr/local/etc/rc.local, which (if it existed) would be automatically sourced in at the end of rc.conf. Ports which built daemons were allowed (well, actually, expected) to ask the user if they wished to activate the port, and if so, the port would add a line of the form 'portname_enable="YES"', and this would make your new port operate. Well, it seems from what I see of my new system, that this is no longer the case. I could understand (and approve of) ports not being allowed to modify any /etc/contents, but howcome ports can't use this rather obvious workaround? I'm pretty sure this used to be allowed... and it seems like a good policy to me, from the number of non-technical folks who now run FreeBSD. I just wanted to know why its not anymore. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
