Project

General

Profile

Actions

Feature #2603

closed

Provide support for Package external name, internal name and service name to be different

Added by Phillip Davis over 11 years ago. Updated about 11 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Package System
Target version:
Start date:
08/22/2012
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:

Description

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


Files

ipguard.txt (2.51 KB) ipguard.txt Phillip Davis, 08/22/2012 03:40 AM
Actions #1

Updated by Chris Buechler over 11 years ago

  • Tracker changed from Bug to Feature
  • Affected Version deleted (2.0.1)
Actions #2

Updated by Phillip Davis over 11 years ago

What design is preferred?
Allow a package to specify both <internal_name> and <service_name> in case they are different?
If <internal_name> is specified, but not <service_name> then default the <service_name> to <internal_name>? (rather than the external package name)
Are the keywords <internal_name> and <service_name> OK, or are different words preferred for these?

Actions #3

Updated by Phillip Davis about 11 years ago

This is completed and working.
The final implementation was to just have the option to specify <internal_name> in addition to <name> for a package. There was no real need to also have <service_name>. For all packages that have a service daemon, the internal_name is the service_name.
Now things like squid3 have internal_name squid, xxx-dev have internal name xxx etc. Startup and shutdown scripts are being called nicely out of /usr/local/etc/rc.d

Actions #4

Updated by Chris Buechler about 11 years ago

  • Status changed from New to Resolved
  • Target version changed from Future to 2.1

thanks!

Actions

Also available in: Atom PDF