On Mon, Jul 23, 2007, Birger Krägelin wrote:
> > > Anyhow, I am wondering why the decision was made to move the milter
> > include
> > > files to milter/*.h instead of the default libmilter/*.h? If
> > something really
> > > needs the includes in milter/*.h maybe a symbolic link should be made
> > so it
> > > works for both locations.
> > > Maybe I am just missing something, but any ideas would be helpful.
> >
> > Simply because a package named "foo" should provide its includes in
> > <prefix>/include or <prefix>/include/foo and not in any other location.
>
> So another decision might be to rename the milter library to
> "libmilter" and provide the include files in libmilter/*.h Milter is
> the actual program running as a mail filter, libmilter is the library
> to link against.
>
> My vote is for a package named "libmilter" with default paths from the
> authors. I vote against patching "mimedefang".
If we would just have the "milter" package I also would vote for
renaming it to "libmilter" immediately. But what about the "milter-xxx"
packages? They use the "milter" prefix to show their correlation to the
"milter" package. Until now all "foo-bar" packages were directly related
to a central "foo" package (e.g. "perl" and "perl-xxx", "python" and
"python-xxx", etc). Sure, we can break this convention here, but is it
worth the effort? The "mimedefang" package is now already fixed and I
don't know at least about any remaining issues.
> I see enough arguments to keep the default paths of software. The
> naming scheme for the OpenPKG packages shold reflect these.
Yes and no. Yes, as long as it makes sense from a consistency point
of view, OpenPKG always should (and actually does AFAIK) follow the
names and paths of the upstream vendor. But, no, if the upstream vendor
decides for a path which doesn't fit very well into the filesystem
layout of OpenPKG (here the "libmilter" example would be still fine,
of course) we definetely will make it fit (and not adjust our side
according to the upstream vendor intentions). There are just too many
existing upstream vendor intentions -- if we too flexibly adjust our
filesystem layout to them, OpenPKG instances would be a mess within a
short timeframe.
But, this is a generic statement here and as an exception does not
really apply to the Sendmail Milter API as a "libmilter" would still fit
into the layout, of course. Just to give you an example what does *not*
fit: <prefix>/include/foo-1.2.3/ or <prefix>/var/run/ as many upstream
authors prefer, or <prefix>/share/man/ and <prefix>/share/info/ as the
newer GNU Autoconf prefers.
So what? Who prefers...
1. to rename "milter" to "libmilter" despite the fact that this
breaks the OpenPKG convention of a central master package "foo" and
sub-packages "foo-bar"?
2. or to keep the "milter" package and the already existing "#include
<libmilter/*>" to "#include <milter/*>" patches in the "milter-xxx"
packages.
Birger voted for (2). I personally still vote for (1) as this means
nothing to be done and to not break the conventions (although it doesn't
follow the upstream vendor intention).
More votes?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
OpenPKG http://openpkg.org
Developer Communication List openpkg-dev@openpkg.org
