Nicolas Williams wrote:
> On Mon, Nov 30, 2009 at 01:51:36PM -0800, Scott Rotondo wrote:
>> I agree that it would be better to integrate these FOSS "familiarity"
>> packages in /contrib, at least initially. It would be a more accurate
>> portrayal of what people are actually getting from us.
>>
>> Part of the problem seems to be that there is no good place to keep the
>> source code. The choices seem to be:
>
> No, that's not a problem, much less the main problem: the /contrib
> effort includes a source repository (see SourceJucr).
I guess I haven't paid as much attention to SourceJuicer as I should
have. I knew that it automated the process of building source and
producing a /contrib package, but I didn't know that it also provided a
permanent repository for the source code or that it rebuilt and
redelivered the packages as needed. Thanks to everyone who set me
straight about that. In that case, I guess there is no need to partition
SFW.
>
> The main problem has to do with usability, trust and perception, and
> boils down to: should /contrib be enabled in default installs?
>
> There may also be other problems such as what happens when a pkg is
> migrated from /contrib to /release, whether folks integrating into
> /contrib are careful about such minutiae as putting section 8 manpages
> in section 4, etcetera. But IMO the usability/trust issue is foremost.
But the "trust and perception" issues associated with /contrib are not
unwarranted given the (very small) Sun engineering effort that goes into
those packages. That seems equally valid for many of the "familiarity"
packages that end up in /release, but it's much harder for users to
figure that out.
So I guess we're in violent agreement that putting such packages in
/contrib would be better for everyone.
Scott
--
Scott Rotondo
Principal Engineer, Solaris Security Technologies
President, Trusted Computing Group
Phone/FAX: +1 408 850 3655 (Internal x68278)
