On 12/14/06, Peter Tribble <peter.tribble at gmail.com> wrote:
>
> On 12/11/06, Kyle McDonald <kjmcdonald at gmail.com> wrote:
> >
> >
> > I'm really trying to move this discussion on the the larger issue, and
> > away from the rmvolmgr package specifically - (neither it nor it's
> > developers are being criticized - at least that's not my intention.)
> >
> > I know that the pkg infrastructure in place isn't very sophisticated.
> > But even with what is in place it seems that more could be done to minimize
> > the 'unused' files from being installed.
> >
> > I would think just making more (smaller) packages with a finer
> > granularity, would go a long way to improving this situation.
> >
>
> Ugh. We already have far too many packages that have no real value in
> being
> separate packages.
>
I aggree with thtat too. Maybe if things that were used seperately were made
available seperately, then we could find usage patterns and recombine them
in a way that makes sense?
What we do need is to apply much more thought to the package boundaries so
> they actually make sense.
>
> One more example of how bad it's getting:
>
> On an S10U3 system:
>
> % ldd /usr/sbin/share
> libc.so.1 => /lib/libc.so.1
> libm.so.2 => /lib/libm.so.2
> /platform/SUNW,Sun-Blade-1500/lib/libc_psr.so.1
>
> On an snv_53 system:
>
> % ldd /usr/sbin/share
<snip>
Ironic. I just hit this last night. I newly jumpstarted machine booted, and
SMF had services that wouldn't start.
the logs showed that /usr/sbin/share couldn't run due to a missing library.
I totally aggree that WBEM/CIM shouldn't be required. (I did end up
installing SUNWdmgtu to get the library in this case though.)
I hope this is fixed soon. Still the libary explosion in /usr/sbin/share
from 10u3 to snv53 is considerable. I wonder what it's from?
libshare.so.1 => /usr/lib/libshare.so.1
> libscf.so.1 => /lib/libscf.so.1
> libsecdb.so.1 => /lib/libsecdb.so.1
> libumem.so.1 => /lib/libumem.so.1
> libxml2.so.2 => /usr/lib/libxml2.so.2
> libc.so.1 => /lib/libc.so.1
> libnsl.so.1 => /lib/libnsl.so.1
> libzfs.so.1 => /lib/libzfs.so.1
> libuuid.so.1 => /lib/libuuid.so.1
> libfsmgt.so.1 => (file not found)
> libuutil.so.1 => /lib/libuutil.so.1
> libpthread.so.1 => /lib/libpthread.so.1
> libz.so.1 => /usr/lib/libz.so.1
> libm.so.2 => /lib/libm.so.2
> libsocket.so.1 => /lib/libsocket.so.1
> libmp.so.2 => /lib/libmp.so.2
> libmd.so.1 => /lib/libmd.so.1
> libdevinfo.so.1 => /lib/libdevinfo.so.1
> libdevid.so.1 => /lib/libdevid.so.1
> libgen.so.1 => /lib/libgen.so.1
> libnvpair.so.1 => /lib/libnvpair.so.1
> libsec.so.1 => /lib/libsec.so.1
> libavl.so.1 => /lib/libavl.so.1
> /platform/SUNW,Ultra-60/lib/libc_psr.so.1
> /platform/SUNW,Ultra-60/lib/libmd_psr.so.1
>
> Now that's just crazy. Not just the length of the list (much of which
> is dragged in along with libzfs), but the fact that a command in SUNWcsu
> has dependencies on files well outside core Solaris. The missing
> library there is from some WBEM package. There's no way I should have
> to start installing random bits of WBEM to make share work. And the
> solution isn't to put libfsmgt into a separate package, it's to move it
> into SUNWcsl. (Hopefully this is what fixing bugid 6496726 will do.)
Or eliminate the need for the library. I know nothing about the design, but
if function or symbol or two could be moved from that library to another,
that might make an even better solution.
-Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/install-discuss/attachments/20061215/25103439/attachment.html>
