splitting courier-authlib into master+slave ports

[Yarema]

--On Thursday, April 21, 2005 7:50 PM +0200 Oliver Lehmann 
<lehmann at ans-netz.de> wrote:

> Yarema wrote:
>
>> Hello again Oliver,
>>
>> Another rewrite, putting some code where my mouth is... ;)
>> <http://yds.CoolRat.org/freebsd/courier-authlib-20050420.01.tgz>
>> This one is based on the latest version you provided.
>
> Other point:
>
> @${CHMOD} -h 0444 ${PREFIX}/lib/${PORTNAME}/*
> I don't like that too - using asterisk is evil imho. None know to what it
> expands. I won't touch the libs after they are installed. They are
> getting installed with the right rights or not. Changing the rights
> later is bad design imho. SowWhat I see is changing the installation
> procedure or just don't touch the rights. I prefer the later. Take it
> as it gets shipped will cause less pain imho. If someone wants a
> restricted modes setup he can change it by his own, or change /usr/share/
> mk/bsd.own.mk. (If someone wants that, he knows what he has to do to get
> it)

Thing is that the provided courier-authlib install targets do not honor 
/usr/share/mk/bsd.own.mk .. I think it's our responsibility as port 
author's to ensure as secure an install of a package as possible.  And 
you're right, the ${CHMOD} wildcard is a lazy way to go about it.  But it 
produces the same results as patching the install routines.  The real 
problem is that with FreeBSD ports we don't have a safe staging area to 
install to and fix all the permissions, delete unneeded files, etc. ... and 
THEN roll a package with everything fixed up just right.   I consider 
${PREFIX} to be a staging area up until the package gets recorded in 
/var/db/pkg/ with an MD5 for every file.  That's why I take the extra steps 
in the Makefile to fix things up.  But I won't dispute that my way of going 
about it is not always prettiest.

I do believe it's better than trusting the author of whatever is being 
ported to know how to install things properly according to FreeBSD Porter's 
Handbook and hier(7) guidelines.  So if a the install routines don't leave 
things with permissions according to FreeBSD conventions they should be 
fixed.  By they I mean the installed files, but if the install routines are 
fixed, even better.

I chose the lazy way to go about it, I admit.  But in the very least I 
think that no binary file (executable or library) should have the write bit 
set no matter what.

Notice that the plugin subports install things correctly via the override 
do-install target.  It's that the master port relies on the provided 
install routines.  And those are not FreeBSD specific so they leave things 
in a less than ideal state.  Writing override do-install targets for every 
port is just impractical.  And figuring out how to patch all the provided 
install routines is an even more Herculean undertaking.  So fixing things 
up in the post-install target seems the most practical.

-- 
Yarema
http://yds.CoolRat.org