One way of viewing the distinction would be components used by users,
But users don't use libraries (developers do, and the apps users use do).
applications and user services to components that are implementation
details or perhaps tied heavily to the system and reflect private
interfaces (to some extent). So a library involved with "storage" or
Implementation details of... what? Surely an implementation detail of
something in /contrib does not belong under system/library, right?
Well if the package in /contrib was linking to libpicl, I would suggest
it's broken as libpicl to me is a systems library. :-)
"dynamic reconfiguration" might be under system/library while a general
event library or something to manipulate PNG files would be under just
library.
Ah, so "implementation details of the core operating system". That's
fine with me. But what is in the "core" will vary over time. Is
OpenSSL in the "core"? Would we always have said that it was? This is
one reason why it helps to make pkg renaming easy! :) :)
I think of "system/library" as being tied more closely to the kernel
than packages under "library". OpenSSL seems more like the latter
rather than the former although obviously in the case of OpenSolaris,
there is some very low-level interaction given the cryptographic
framework, etc.
So to ask a more general question, assuming most of the libraries
aren't "system" libraries, should we be separating them in the package
namespace based on their rough area (security, network, storage,
graphics, audio, etc, etc) or do we see just a flat namespace under the
top-level "library" (this is for libraries that are not already under
some other top-level name like "x11" or "gnome", etc, etc)
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
