Subject: Ported software

From: "Charles M. Hannum" <[email-masked]>

Since someone brought it up, I thought I'd mention what I would like
to see in a ported software archive.

1) There should be diffs from the base distribution available, as well
as a pointer to the base distribution.  These should probably be
stored in a different directory than the complete source, so they are
easy to separate.  Preferrably, there should be no diffs at all.  (See
next point.)

2) When you port a package, you should communicate with the author to
get NetBSD support put in the base distribution.  (Keep in mind that
the author/maintainer may not like your first cut of patches.)  This
is the best thing you can do for the community as a whole; it helps
the author become more aware of porting issues, it helps you not to
have to maintain a separate version of the package, and it helps other
NetBSD users because they can pick up the package from anywhere and
have it `just work'.

3) Everything should install in /usr/local.  I could be convinced that
some other hierarchy is appropriate, but there should not be more than
one hierarchy for the ported software as a whole.

4) Converting everything to use the NetBSD build scheme is a short
road to Hell, as that makes it much harder to import new versions of
packages.  On the other hand, some kind of coherent build scheme would
be nice, even if it only allows for `make all; make install; make
clean'.  I've seen a number of schemes for this in the past, and
almost all of them involve far too much hair for my taste.

5) It would be useful to integrate this with the NetBSD install
system.  The current mechanism allows for optional installation of
packages, but not deinstallation.  It also has no way of running a
post-install or post-deinstall script to munge other system files.
Both of these are (unfortunately) necessary for a complete optional
install mechanism.  They should be relatively easy to do.

All told, it should certainly be done, but this is not an offer to do
it.  B-)  I'm willing to look over ported packages as my time permits,
though, and I'm willing to help define the layout and installation
tools.

---

From: der Mouse <[email-masked]>

> 3) Everything should install in /usr/local.  I could be convinced
>    that some other hierarchy is appropriate, but there should not be
>    more than one hierarchy for the ported software as a whole.

I'm not sure what you mean by the part after the last comma - do you
mean that (a) the package should demand to live under a single root
point, (b) that it should be capable of living under a single root
point, or (c) b plus when so configured, changing that point involves
changing just one thing?

In my opinion, (a) is a bit obnoxious but tolerable with symlinks if
necessary (eg, binaries on a RO filesystem and save files on a RW
filesystem), (b) borders on necessary, and (c) is nice but not
essential as long as all the things that need to be changed are close
together (eg, adjacent lines in some file).  It's nice to have

	#define TOPDIR "/usr/local/foopkg/"
	
	#define BINDIR TOPDIR "bin/"
	#define MANDIR TOPDIR "man/"
	#define LIBDIR TOPDIR "lib/"

but it's not essential; I can live just fine with

	#define BINDIR "/usr/local/foopkg/bin/"
	#define MANDIR "/usr/local/foopkg/man/"
	#define LIBDIR "/usr/local/foopkg/lib/"

What I would have trouble putting up with is having those strings
scattered throughout multiple files, or not present in a single
easily-modifiable form.

(As for /usr/local as the place of choice, well, personally, /usr/local
is as useless as /usr/bin; if it can't go in a directory of my choice
under /local, it generally doesn't go anywhere but /dev/null.)

					der Mouse

			    [email-masked]

---

From: [email-masked] (Ty Sarna)

> NetBSD users because they can pick up the package from anywhere and

I don't think this can be emphasized enough.  It's also nice for users
of other OSes to not have to wade through NetBSD versions to find the
standard distribution.  I don't know how many times I've archied for a
piece of software and had to sort through umpteen dozen &*^*&*&% Linux
versions before finding the standard version.  Please, let's not us
inflict that on others... 

> install mechanism.  They should be relatively easy to do.

How about adopting the FreeBSD pkg_* tools? They seem to do the job. Is
there a reason for not using them?

-- 
Ty Sarna                   "You can lead a gift horse to water but 
[email-masked]          you can't make him look you in the mouth"

---

From: "Charles M. Hannum" <[email-masked]>

How about adopting the FreeBSD pkg_* tools?

Last I knew, they were not at all integrated with the installation of
the base system.  It would be preferrable for the two to be the same;
even the `base' system has `optional' packages that the user may not
want to install (or may want to deinstall later).

---

From: Andrew Cagney <[email-masked]>

Hello,

Oh, no, another $$ worth ...

Some brief notes on what I look for when installing large packages (eg.
Ileaf, FrameBuilder, Ingres, AUIS, ...).  Most people won't look for (or
need) any thing like this.  If you are going to start packaging things,
you may wish to keep these points in mind.

While reading keep your salt grinder handy :-)

	o	Package install under their own top level.  It can also have a
		second `home' directory for scratch stuff.
		Eg /vend/ileaf-6.0 and /home/vend/ileaf (and a link
		/vend/ileaf -> ileaf-6.0).

	o	You can tell the installation procedure lies and it will believe you
		eg /vend/ileaf-6.0 is really /amd/dobson/fuji/vend/ieaf-6.0.
		ie packages that go INSTALL_DIR=`/bin/pwd` sux.

	o	Can be adminstered from an ordinary (dedicated) account.
		i.e. often get their own UID=GID.

	o	The installation point can be decided at installation time.
		If at all possible, please don't impose a hard wired
		directory.

	o	As far as possible, doesn't require *any* thing in a users
		environment to run.  i.e. /<xxx>/<package>/bin/<command>
		hopefull works.
			-> NO LD_LIBRARY_PATH stuff
			-> NO PATH
			-> NO Other variables
		If all else fails, /usr/local/bin gets a script that wraps
		up the mess.  (eg run-<package>).

		Suites of utilities are the exception (eg TeX, psutils, `gnuutils').

	o	Doesn't create potential name space polution problems by
			o	Requiring everything to have an
				alias in /usr/local/bin
			o	requiring ldconfig commands to
				find dynamic libraries
				*[NetBSD currently can't do this]*

	o	It's the end user, not the adminstrator, that decides which things
		to put into a PATH name space.

	o	Some times (just some times) I'll put `an alias' in
		/usr/local/bin.

	o	I can make the package accessable from a double click icon
		(and may be a menu entry).  Have look at VUE (HP) or ODE.

				Andrew

PS: Sorry, like "Charles M. Hannum" <[email-masked]>, I can't
help with this but probably could manage a few comments.

---

From: [email-masked] (Jesus M. Gonzalez)

Again here...
> ...

	Beeing in the front of those who think that source packages
should be modified as little as possible, I think we should
stuck to what the package does. They use to have a TOPDIR or something
like that defined. Or they can be easily taugth to use one. So, the
thing maybe shouldn't be "what do we want for source packages" but
"how do we deal with source packages as they are".

	On the other hand, things are different fo rbinary packages.
I think it is important to agree on a schema, so that a user
can just take the bin packages of her choice, install them
---if possible with some automated tool---, and just begin to play.
I think that means agreen on where to put things *exactly*
---or maybe with a small degree of flexibility using symlinks...
> under /local, it generally doesn't go anywhere but /dev/null.)

	I agree again, except in "my choice". Again, I think binary
packages should be to a determined place. Of course, with
src packages, enyone can do whatever she likes...

-- 
Jesus M. Gonzalez Barahona    | Universidad Carlos III (Madrid, Spain)
tel: +34 1 624 94 58          | e-mail: [email-masked]
fax: +34 1 624 94 30          |         [email-masked]
(Sometimes our headers are not o.k., please reply to any of this addresses)
.From within Universidad Carlos III, you can better use [email-masked]

---

From: [email-masked] (Jesus M. Gonzalez)

> one hierarchy for the ported software as a whole.

	Well, I agree that binaries should install somehwere
under /usr/local, but as I said, not *exactly* in 
/usr/local/{bin,man,lib}. I again prefer links, life is easier
when deleting packages or upgrading to new versions if you
use separate directories for aech package.

> almost all of them involve far too much hair for my taste.

	I agree. I think we should make things a easy as possible,
specilly when tracking new versions. And easiest way is just
touch configure, or makefile or whatever for specifying the dir
for installation, and run make. 

> install mechanism.  They should be relatively easy to do.

	Could someone talk a bit about "the NetBSD install"? I'm
still stuck with NetBSD 0.9a, and don't what is that... Anyway,
I feel it will be necessary a deinstallation tool, and thins like
running scripts before and after installing/deinstalling.

> though, and I'm willing to help define the layout and installation

	Well, maybe somebody should sumarize the present discussion,
and interested users could send comments... Specially if we are 
talking about a schema for binaries, it is important to agree in
some things a installation dirs. If not, all those packages that
depend on where they are installed to work properly will be
a true headache...

	By the way, in other message, somebody talked about using
FreeBSD's pkg*. I tried it sometime ago, and I stopped using it
because of it put everything directly in /usr/local/{bin,lib,...}.
See avobe, I don't think that is the best thing we can do. Anyway,
it can have changed in the meantime. And of course it could
be a good starting point...

	(Does anybody know how deal with this Linuxed people?)

---

From: [email-masked] (Ty Sarna)

> want to install (or may want to deinstall later).

Is there any reason the pkg tools can't be used for the base system as
well?