Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

[Matthias Andree]

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: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

[Robert Watson]

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: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

[Richard Coleman]

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)

[Richard Coleman]

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)

[David O'Brien]

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)

[Robert Watson]

On Mon, 1 Dec 2003, Maxim M. Kazachek wrote:

> On Sun, 30 Nov 2003, Richard Coleman wrote:


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)

[Maxim M. Kazachek]

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/.
>>
>> 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)

[Richard Coleman]

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: 5.2-BETA and related ports issues

[M. Warner Losh]

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]

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

[Michael Edenfield]

* 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: 5.2-BETA and related ports issues

[Oliver Eikemeier]

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]
 
___
[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

[Richard Coleman]

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

[Oliver Eikemeier]

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:
 
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]

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

[Richard Coleman]

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: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

[Richard Coleman]

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/.
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]

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: 5.2-BETA and related ports issues

[Melvyn Sopacua]

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

[Andreas Klemm]

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: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

[Andreas Klemm]

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:
> >
> >
> >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/.

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

[Robert Watson]

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: 5.2-BETA and related ports issues

[Richard Coleman]

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: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

[Richard Coleman]

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:


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]

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: 5.2-BETA and related ports issues

[Andreas Klemm]

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

[Oliver Eikemeier]

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:

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

[Andreas Klemm]

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:
> 
> 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

[Oliver Eikemeier]

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

[Oliver Eikemeier]

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:

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: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

[Oliver Eikemeier]

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 2>&1 >/dev/null || true
openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 2>&1 >/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:

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

[Mark Linimon]

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: 5.2-BETA and related ports issues

[Dag-Erling Smørgrav]

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

[Kris Kennaway]

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

[Dag-Erling Smørgrav]

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]"

Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)

[Kris Kennaway]

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 2>&1 >/dev/null || true
> openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 2>&1 >/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]

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

Re: 5.2-BETA and related ports issues

[Richard Coleman]

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 2>&1 >/dev/null || true
openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 2>&1 >/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

[Andreas Klemm]

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

[Dag-Erling Smørgrav]

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

[Andreas Klemm]

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 2>&1 >/dev/null || true
openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 2>&1 >/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

[James Raftery]

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]"

Re: 5.2-BETA and related ports issues

[Christian Laursen]

"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]"

5.2-BETA and related ports issues

[Michael L. Squires]

Things are actually looking pretty good at this point; I'm probably going
to move from 4.9-STABLE to 5.2-RELEASE on my main home server, but I'm
seeing the following with 5.2-BETA at this point:

I'm running 5.2-BETA cvsup'd at about 9 PM 11/25 on two systems; one is
a Supermicro P6DGH, dual PIII/850, SCSI disks, Compaq/Intel Pro100+ NIC;
the other is a Toshiba 8100 Tecra using the built-in 3Com 10/100 port
in the docking station (xl driver).

The P6DGH is running netatalk with the (apparently) as yet uncommitted
patch to the netatalk kernel interface, which appears to be running fine.

I am not seeing any IP lockups (just finished a buildword/buildkernel/
installkernel/installword cycle with the portable NFS mounting the
P6DGH).

The following appeared before 5.2-BETA but are continuing with that version.

On the portable I'm getting the following lock order reversal:

Nov 28 10:32:33 mikes-port kernel: lock order reversal
Nov 28 10:32:33 mikes-port kernel: 1st 0xc340eb00 pcm0 (sound softc) @ 
/usr/src/sys/dev/sound/pci/ds1.c:734
Nov 28 10:32:33 mikes-port kernel: 2nd 0xc340e740 pcm0:play:0 (pcm channel) @ 
/usr/src/sys/dev/sound/pcm/channel.c:440
Nov 28 10:32:33 mikes-port kernel: Stack backtrace:

The related parts of dmesg are as follows (an improvement from 5.1-CURRENT,
where the AC97 driver didn't load):

pcm0:  port 0xbf3c-0xbf3f,0xbf40-0xbf7f mem 0xefdf8000-0x
efdf irq 11 at device 12.0 on pci0
ds1: setmap (226000, 3de4), nseg=1, error=0
pcm0: 
pcm0: Codec features headphone, 18 bit DAC, 18 bit ADC, 5 bit master volume, AKM
 3D Audio
pcm0: Primary codec extended features variable rate PCM, AMAP
pcm0: sndbuf_setmap 135db000, 1000; 0xc3407000 -> 135db000
pcm0: sndbuf_setmap 13579000, 1000; 0xc3405000 -> 13579000
pcm0: sndbuf_setmap 13134000, 1000; 0xc340 -> 13134000
pcm0: sndbuf_setmap 134b2000, 1000; 0xc341e000 -> 134b2000
pcm0: sndbuf_setmap 134d, 1000; 0xc341c000 -> 134d
pcm0: sndbuf_setmap 1348e000, 1000; 0xc341a000 -> 1348e000

postgreSQL startup called twice

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.

The plus side is that a lot of the ACPI errors I used to get on the
admittedly wierd P6DGH (11 PCI slots, onboard I2O, etc) have gone away.

I'm not adding anything else at this point, since I don't know if these have
been already reported (or fixed), but I can provide other info if necessary.

Mike Squires
UN*X at home
since 1986
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"