On Mon, Jan 25, 2010 at 04:26:22PM -0800, [email protected] wrote:
> >>One way of viewing the distinction would be components used by users,
> >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. :-)
Sure, but only if libpicl provides no public interfaces.
> >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)
I've thought about this, and here are my tentative conclusions:
With any multi-level pkg naming scheme with generic top-level labels
you are providing a classification system. There can be only one
canonical name for any pkg.
In addition you're also providing a separate pkg classification
system where a pkg can be in multiple "classes"; this provides for
"aliases" for pkgs, and, at any rate, simplifies browsing for pkgs.
Conclusion #1: You cannot avoid oddities in pkg naming with any
multi-level pkg naming scheme. Resolving such
oddities will be a matter arbitrary rules, aesthetics,
taste, consensus...
Conclusion #2: Your multi-level pkg naming scheme is somewhat (very!)
redundant because it replicates part of the generic
pkg classification system.
My advice:
In order to a) minimize arguments about pkg naming, b) avoid the
redundancy pointed out in conclusion #2 above, you might be better
off retaining a flat or flattishpkg namespace where the top-level is
more specific / less generic than the ones you've been using.
For example, java6/runtime instead of system/java6/runtime. I.e.,
the top-level labels in pkg names should name a family of very
closely related pkgs. Top-level labels in pkg names should not be
generic labels like "system", "library", "desktop", etcetera.
Alternative advice:
Given that you have a better pkg classification system, and that pkgs
can easily be renamed now, you can defer all arguments about pkg
naming until you have time to engage in them. IOW, pkg naming is
really not a big deal, oddities and all. :)
Nico
--
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
