On Aug 25, 2009, at 3:15 PM, Shawn Walker wrote:
Jonathan Edwards wrote:
(1) a package contains a binary or driver you might want, but you
don't care about the GUI component that's also in the package ..
the GUI dependencies are "require"d but you don't really want them
since you don't want to pull in the entire windowing environment.
The creator of the package has stated that the software delivery is
not complete without the GUI component. File a bug with the package
maintainer to fix the package if that is not the case.
okay if we need to talk specifics .. but let's not just talk about the
specifics of each particular case - i don't think it's worth anyone's
time to write long diatribes to attempt to document every specific use
case for much larger problems that can be imagined
- let's say that you have an administrator who'd like to run a
headless opensolaris server .. in other words no windowing system.
However - he does have a local X display that will work fine for
throwing applications back to like say .. firefox .. he doesn't care
about ogg, nor the gnome dependencies - yet these are required for the
components within the package for the included components that need
them .. so what's the "correct" way of packaging here? create
multiple smaller packages and then chain them together into a larger
dependent cluster and then leave it to the administrator to piecemeal
what they do and don't need? or simply allow someone to install a
bundle unconditionally and rip out what they don't want? .. which one
is closer to KISS?
(2) there's no mechanism for an OR .. in other words - let's say
that package A has a requirement for a certain library, but that
requirement could be met by either package B (which pulls in
packages C, D, E, F) .. or package X (which only pulls in packages
Y and Z)
Do you have an actual, specific usage case? At best, every time
we've discussed this in the past, only hypotheticals have been able
to justify it.
pkg(5) does have the concept of 'optional' dependencies which could
satisfy this scenario leaving the user to choose which one to install.
sure .. Darren's database example is one .. eg: a database is
required, say, but you can pick one from a list - (not quite the same
as an optional dependency) ..
KDE vs Gnome is another .. or dropped down a level - window manager
choices (ice, flux, compiz, etc) .. or even lower Xorg or Xvnc (ie:
headless example above)
scanning some of the dependencies in the manifest tree - SUNWbash
dependencies looks like another potential hot-button
(3) the customer has their own custom packages which provides
proper dependencies for package A and knows this.
Then they should name their package 'package A' and use the
preferred publisher mechanism we currently have to override that
other package.
so building off the example of SUNWbash - this is starting to sound an
awful lot like the old "ln -s /bin/bash /bin/sh" (or the "export
PATH="/usr/gnu/bin:/usr/bin:..") trick .. in other words if the proper
way to solve this is for someone to effectively trojan their package
to satisfy the package A dependency - i believe that something is
broken in the methodology
(4) there is a known security issue with package E .. hence no easy
way to extract that package from the mix and replace it
There is actually. Name your replacement package 'package E', then
publish it, and set the publisher for its repository as 'preferred'.
in more extreme cases if you needed to remove package E - i guess you
could simply publish an empty package here, but that seems like a
broken dependency methodology to work around the inability for someone
to intentionally break a dependency
cheerios
Jonathan
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
