>
>
>
> Judgmental terms like "wrong" are so strongly dependent on your
> perspective.


Ok. maybe 'wrong' is too strong. How's 'poor design'? 'inflexible'? 'less
than desirable'?

It might be better if there were fewer dependencies, or if some of the
> dependencies were looser, I guess, but that's something that can be
> worked at over time.  We had such functional deficiencies in the system
> that this was overall a better choice than continuing to saddle
> (Open)Solaris with a clearly non-competitive removable media solution.


I understand that there are  probalby many very good reasons for the
rmvolmgr pkg to have been added over SUNWCvol. And, admittedly,  I probably
don't even understand them all. I accept the argument that it's an
improvement. I'm not arguing that we didn't need it or it should have been
done.

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.

I mean in this particular case, it seems the dependency is not on
SUNWgnome-base-libs, but on libglib.so.
I don't know which of SUNWgnome-base-libs's dependencies are there because
of libglib.so, and which are from the other parts of SUNWgnome-base-libs. It
seems to me to that just splitting out a SUNWlibglib package would help in
this and possibly other situations. Possibly it would make sense to split
out most shared libraries into separate packages.

Ideally I'd like to see a layered set of packages, where all the
dependencies are on things on lower layers -possibly dependencies on things
at the same layer, but no upward layers.  There should be a base foundation
for all packages, and then things that lay the foundation for other subsets
of packages, but you shouldn't see foundation packages requiring 'leaf' or
'application' upper layer pacakges.

I think that (to some extent) this could be achieved through package
re-organization, without a new package framework or file format.

What I wish we had now, to analyze all this, was info about the specific
files (or maybe interface is a better term) needed by a package when it
'depends' on another package. That alone might allow some automated analysis
of what libraries,files, etc. to split out into separate packages.

Even so I may take a stab a writing up some analysis of the 'depend' file in
each package.

In my trials lately, the worst case I've come along has been XscreenSaver,
which somehow has the system asking me to install all sorts of things like
print functionality and Evolution. I've mentioned this one before. But it's
a good example, where the dependency tree is over 6 layers deep. I know that
if the packages were just split up at a finer resolution, then much of this
'excess' could be eliminated.

Java, even though it should run from the command line only, is another
offender - requiring pieces of the X11 runtime to be installed.

As a desktop system, I actually like GNOME. It's a great improvement over
CDE, and better than KDE. I'm just not sure that letting it grow it's roots
deeper in to the rest of Solaris is a wise thing. Shouldn't we be making
minimization easier? not harder?

If this all really requires a new packaging system, then maybe that should
be worked on sooner than some of the other (more visible) things? In my
opinon at least we are putting the cart before the horse in some ways.

-Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mail.opensolaris.org/pipermail/install-discuss/attachments/20061211/74c5aac3/attachment.html>

Reply via email to