>>>>> "Rainer" == Rainer Orth <[EMAIL PROTECTED]> writes:

Rainer> Btw., I'm currently working on
Rainer> 
Rainer>     6414822 don't try to build packages with closed components
Rainer>
Rainer> again.  
[...]
Rainer> Btw., do I need to file a new bug for this work (splitting off
Rainer> packages), or can this be handled with the same CR?

It can be done as part of 6414822, assuming it all goes back at the same
time.

Rainer> f kernel/crypto/sparcv9/dprov  -  755 -  -  246202  2  -  -  proto
Rainer> f kernel/drv/dprov.conf        -  644 -  -       0  1  -  -  proto
Rainer> f kernel/drv/sparcv9/dprov     -  755 -  -  246202  2  -  -  proto
Rainer> 
Rainer> SUNWcryptoint
Rainer> 
Rainer> Distributed in source; the only parts missing from SUNWcryptoint
Rainer> are etc/certs/SUNWosnetSolaris and etc/crypto/certs/SUNWosnet.
Rainer> Perhaps those should go into their own packages?  Any
Rainer> suggestions for a name?

Yes, SUNWcryptoint. ;-)

Seriously, I think the right approach here is to keep the internal certs
in SUNWcryptoint, and split dprov--which is just an example driver--into
its own package.  I'm not sure what a good name would
be... SUNWcryptodemo?  This sounds like a question for
security-discuss.

Rainer> d usr/include/sys/ib/adapters/tavor - 755 - - 101637 2 - - proto
Rainer> 
Rainer> SUNWtavorh (new)
Rainer> 
Rainer> distributed in closed tar ball, but should be removed

Yeah, my first reaction is that the closed tar ball should not include
any empty directories.  (And that the current empty directories are a
bug that wasn't important enough to fix until now.)  But in a followup
posting there was some mention of empty directories that need to be in
the closed tar ball?  Could someone explain that to me...?

Rainer> f usr/include/sys/scsi/adapters/ifpio.h - 644 - - 0 1 - - proto
Rainer> 
Rainer> SUNWifph (new)

Actually, there's already a SUNWifph.

Rainer> Distributed in uts/sun/sys/scsi/adapters/ifpio.h, but only
Rainer> referenced in uts/sun/sys/Makefile, should probably be moved to
Rainer> closed tree unless the other headers in the new SUNWifph package
Rainer> can be opened, too.

It's needed by the NWS consolidation, so moving it to the closed tree
would be a problem.  

There are a couple other drivers that have this same issue--the driver
itself is closed, but there is an interface header file in OpenSolaris
that NWS requires.  So maybe these should all go into a single package?
I don't like that answer, but I don't like having SUNWifph and
SUNWifph-open, either.  Can someone think of a better option?

Rainer> SUNWiotu
Rainer> 
Rainer> The only parts missing from SUNWiotu are pcitool and pcitool.1m.
Rainer> Perhaps those can be released or split off to their own package,
Rainer> since all the drivers are present in source?
[...]
Rainer> SUNWonmtst.i
Rainer> 
Rainer> So from this package, only usr/bin/mtst is missing.  

Either of your suggestions for pcitool is okay with me.  pcitool and
mtst were moved to closed source fairly late in the Pilot program for
reasons I probably can't go into.  The idea was to revisit that decision
after the craziness of the launch.  I suspect that this has fallen on
the floor, but I've pinged Bonnie to see if she has more information.

Rainer> s usr/lib/libsmartcard.so        libsmartcard.so.1    777 -  -  0  1  - 
 -  proto
Rainer> f usr/lib/libsmartcard.so.1      -    755 -   -   0  1  -  -  proto
Rainer> f usr/lib/llib-lsmartcard        -    644 -   -   0  1  -  -  proto
Rainer> f usr/lib/llib-lsmartcard.ln     -    644 -   -   0  1  -  -  proto
Rainer> s usr/lib/sparcv9/libsmartcard.so libsmartcard.so.1   777 -  -  0  1  - 
 -  proto
Rainer> f usr/lib/sparcv9/libsmartcard.so.1 - 755 -   -   0  1  -  -    proto
Rainer> f usr/lib/sparcv9/llib-lsmartcard.ln - 644 -   -   0  1  -  -    proto
Rainer> f usr/sbin/ocfserv               -   555 -   -    0  1  -  -    proto
Rainer> 
Rainer> SUNWocf
Rainer> 
Rainer> Distributed in closed tar ball, but should be removed: I
Rainer> couldn't find a reference to -lsmartcard in the build logs.
[...]
Rainer> f var/svc/manifest/network/rpc/ocfserv.xml - 444 - - 0 1 - - proto
Rainer> 
Rainer> SUNWocfr

I believe that the smartcard code is supposed to be EOL'd and removed
completely, but I'm unsure of the timeframe.

In the meantime, as someone (Richard?) noted, the closed tar ball can
also be redistributed in non-Sun distros.  So removing the smartcard
bits from the tarball seems like the wrong answer to me.  What happens
if you leave these packages in usr/src/pkgdefs?

Rainer> I hope the currently missing sources that can be opened can be
Rainer> moved over to the open tree at the same time as the patch above
Rainer> goes in.

Steve has sent me a pointer to the webrev.  I'll try very hard to get it
reviewed this week.

mike
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to