pfSense

Startup and shutdown code currently has lines like:
start_service($package['name']); /* rc.start_packages line 57 */

This assumes that the package name and service name are the same. But now this is not true for more packages that I find - squid3 ipguard-dev (all the ones with "-dev" at the end). I can't see how a package can record in the <package> section what its internal name and/or service name is.

At startup and shutdown there are messages like:
--------
Starting package Ipguard-dev...done.
Starting /usr/local/etc/rc.d/ipguard.sh...done.

Stopping package Ipguard-dev...done.
Stopping /usr/local/etc/rc.d/ipguard.sh...done.
--------
These look really odd starting and stopping these things twice.

This issue should be the same in 2.0.1 and 2.1

Current general package support code could try to guess by:
1) Lowercase the package name,
2) See if there is a service with matching name - if so, great
3) Take 1 character off the end at a time
4) Go back to 2 and check for a match

So squid3 would find the service squid, ipguard-dev would find the service ipguard.
But this is really open to Murphy and packages that are substrings of each other (squid and squidguard).

It would be much better (IMHO) if each package could specify and internal name and service name that were different from the package name. In <package>, as well as <name> allow optional:
<internal_name>
<service_name>
(could be just 1 - and assume that internal_name and service_name are always the same? I never like to assume - Murphy gets me every time.)

Package support code that traverses the <package> XML array for all the packages can then check to see if the package has specified a different <internal_name> or <service_name> and use that instead to access the <installedpackages><_internal_name_><config> or the correct entry in the <service> array.

I have attached an example of a <installedpackages> XML section for ipguard that illustrates the issue.

Once it is decided that this is a good idea and a design option selected, I am happy to code it.
(I left this as a categorised as a bug - but I guess people have lived with this for ages and maybe just put up with it and might call it a feature.)