Subject: Re: Four pkg building design questions
To: None <david@fundy.ca>
From: Alistair G. Crooks <agc@ftp.netbsd.org>
List: tech-pkg
Date: 01/24/2000 01:36:27
My opinions only...
> For convienience, it's multiple choice, but feel free to make
> new recommendations - I'm not doing statistics ;-)
>
> These are some things someone (me :-) might like to know when assembling
> a pkg. Is there an authoritative answer to any of these?
>
> 1. When a FreeBSD port exists, importing it and making changes from there is:
> (A) Required
> (B) Required, if the NetBSD pkg draws from it.
> (C) Preferred (criteria?)
> (D) Optional (criteria?)
(E) Sub-optimal. pkgsrc has moved a fair way from the FreeBSD ports tree.
And they have made subsequent changes to it which we have not pulled up
(for various reasons). Personally, I prefer to build a NetBSD package
where possible - I have found that it takes less time than trying to
convert a FreeBSD port.
> 2. Packages with libs or includes should have their own directory in
> $PREFIX/[lib/include] when:
> (A) Any of their files have non-standard extensions (.a .so .h)
> (B) Any of their files have generic names (parser.h list.h ...)
> (C) The package has more than 2 files.
For header files, where a file would conflict with something in-tree
(like curses.h or list.h), it should go in ${PREFIX}/<pkg>/<include.h>.
Libraries usually do not have name clashes, although I'm sure there
will be someone around to point out the exception. The trouble
with libraries, especially shared ones, are the library paths for
ldconfig (on a.out).
> 3. contrib type files, like example scripts for use with a pkg should be:
> (A) installed in share/doc/(pkg)
> (B) installed in share/example/(pkg)
> (C) installed in bin/ (Even if it forces otherwise unneeded DEPENDS on perl?)
example scripts go in ${PREFIX}/share/example/<pkg>. Documentation goes
in ${PREFIX}/share/doc/<pkg>. Every dependency on Perl is unnecessary.
> 4. libraries distributed with a package should be:
> (A) Treated as part of the package
> (B) Broken out into their own package
> (C) B, if likely to be used by other packages.
> (D) A or B at packager's discretion (criteria?)
A lot depends on the package itself. It's best to contact the
packages people, who will be happy to give you advice. Normally,
I would just have them as part of the package, but that depends
what else is in the package.
Take care,
Alistair