Alex Kapranoff wrote: > * Oliver Eikemeier <eikemeier_at_fillmore-labs.com> [July 29 2004, 12:39]: >> I'm not sure if we should filter out *all* scripts with extensions. >> There might be a startup.app port we like to add, perhaps just a list >> of >> values like `.old', `.sample' e.t.c. should be filtered out. OTOH this >> is easily changeable, should the need arise. > > And startup.app port can easily be started with startup_app script, > This is a non-issue, I think. Jup, I'm thinking in terms of complexity and POLA here, not functionality. >> which will install `apache' or `apache.sh' depending on OSVERSION. A >> variable RC_SUFX is set that could be used in pkg-message or other >> places when necessary. > > The need for two versions of startup scripts for each port is highly > undesirable. There should be some shims for 4.x systems, I suppose, > for them to be able to execute extensionless rc.d scripts in simple > lexicographic order (and missing all the rcorder benefits). No, every port just has one version of a startup script, it is just *installed* under a different name, depending on OSVERSION. The borderline is not 4.x/5.x, it is before/after the patch (which enables execution of extensionless rc.d scripts). The supporting code in bsd.port.mk could install shims that enables newer 5.x packages to be used on older systems, but I would prefer not to have them. >> Sourcing port scripts is not possible with this patch, which is a good >> thing IMHO. Also some documentation needs to added to rc(8) before this >> patch can go in. > > I like the patch and would like it to go into the tree instead of > Mike Makonnen's solution. Sourcing 3rd party (ports) scripts into the > shell > which performs global system startup procedures worries me. Thanks. Mike's patch sources scripts only into localpkg, so there is an additional layer, yet they can influence each other (by erroneously setting common variables). I can not see what sourcing ports scripts should be good for, though. -OliverReceived on Thu Jul 29 2004 - 12:07:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:03 UTC