>I've been thinking of contributing where I can with new packages.
>However, I have a few questions about the ground-rules for doing this...
>
>1) How should I handle Intel vs. AMD and 32 vs. 64 bit packages? Must I
>choose the lowest common denominator, or can I mix and match?
Typically in Solaris, you would ship:
32 bit libraries in $BASEDIR/lib
64 bit libraries in $BASEDIR/amd64
create 32 bit exectuables compiled for the lowest common denominator,
unless there's a compelling reason to also include 64 bit executables:
- better performance
- need for more than 2 or 3 GB of virtual address space
In Solaris, we employ basically two tricks for 'bitness independene':
- the binary found in $PATH is a 32 bit launcher program called
"isaexec" and the 32 bit binary is in i386 and 64 bit in amd64:
$BASEDIR/bin/prog - isaexec copy/link
$BASEDIR/bin/i386/prog - 32 bit copy
$BASEDIR/bin/amd64/prog - 64 bit copy
When using things like SSE2 and such, it becomes a bit more difficult, as
currently don't implement more isa options than:
amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
(isaexec will, I think, try each of those in turn)
>2) Where should things ulimately end up? Example:
>
>Suppose I wanted to make a qmail installation package, currently qmail
>installes by default to /var/qmail. Is this the right place to put things.
>Should things go in /usr/local or somewhere else?
Ah, well, there you would need to use your judgement.
if you use /var/qmail there's a chance that an official distribution
or SFW contributed version will stomp on that location
(this might not be an issue)
if you use /opt/YOURNAME/var/qmail then it might be a bit more
difficult to administer.
If you pick "/" as your abse, try and make things fit nicely with Solaris:
- proper owner/modes for system directories included in packages
- don't create non-package specific directories which do not exist
(like libexec which Solaris does not use)
>3) What features should be supported? Example:
>Suppose I wanted to make a msmtp installation package so a sendmail daemon
>won't need to be running all the time? There are options for kerberos to
>be included. Can I make the decision NOT to include this option. If I do,
>how do I mark the package so people who need this feature will know it's
>not available.
This is in some cases a difficult question. Sun used to ship two
different sendmail binaries, one support MX records and one not supporting
them.
In source packages, it generally does not matter if you make features and
options depenendent on #ifdef USE_KERBEROS or not. And then it doesn't
matter that -DUSE_KERBEROS means that you MUST use Kerberos and that
-UUSE_KERBEROS means that you CANNOT use Kerberos.
However, from a binary distribution's point of few such compile time
options are evil; and whichever configuration you pick will not work
for everybody.
If the -DUSE_KERBEROS just tells you to configure the ability to use
Kerberos but doesn't require you to use Kerberos, then you should/must
include it.
Compile time features which cannot be disabled once compiled in should
be rewritten; you can contribute such changes upstream so all binary
distributions can benefit. (It often is one of the more difficult
parts of getting freeware into a Solaris binary distribution)
>4) What about third party libraries? Example:
>For msmtp, I need to have several gnu libraries, such as gsasl to build/run.
>Do I need to make separate packages for these? Should I use "standard"
>packages like openssl over the gnu packages when possible?
If possible, use OS included libraries; if not, then building libraries
so that they can be reused by packages is fine, however, before you know
it you'll become as big as Blastwave.
>5) What about conflicting products. Example:
>In both of the packages above, or a Postfix package, the "sendmail"
>program must be overridden with the one in the installing package.
>How does something like this get resolved? Do I just rename
>the existing sendmail program? Does the "last one installed" win?
SMF supports multiple different instances of an SMTP service, but the
/usr/lib/sendmail path remain important.
It could be that it is best to signal a conflict with the sendmail package and
require sendmail and postfix to be uininstalled before qmail in installed,
and vice-versa.
Or perhaps you can define a mechanism with makes /usr/lib/sendmail yet another
mechanism which checks the configured mail service and invokes the appropriate
mailer.
>Where can I find the answers to these kinds of questions and others about
>IPS when they become app arent?
Here, perhaps, though this mailing list is perhaps too general.
Anyway, much of thi sis part of the collective knowledge of people
building software for Solaris so asking us is the best thing to do; then when
time passes and it becomes clear which questions are asked often, we'll go
and create an FAQ about this business.
Casper
