Peter Tribble wrote:
On Tue, Aug 25, 2009 at 10:00 PM, Bart Smaalders<[email protected]> wrote:
[email protected] wrote:
We're not preventing you from doing your job, we're trying to prevent
you from building a broken default configuration.
Pkg A contains a hardlink to a file in pkg B, and has a
require dependency on pkg B as a result. If pkg A is installed
with --nodeps, and package B is not installed, what should happen?
The system should warn the user that a dependency is missing, and *leave
it to the user* to accept the consequences.
Well, in this case that means that package A cannot be installed.
Should we just drive on, spewing error messages "because the user
knows best"?
This packaging system is designed to support the installation of
software according to the parameters laid down by the publisher.
The design of variants and facets, for example, is driven by
the need of the publisher to specify the supportable alternative
configurations of his/her product; the removal of arbitrary portions
of a package (including dependencies) at the whim of the administrator
can and _will_ produce arbitrarily broken results.
Define broken. The package dependencies only reflect a single meaning
of "working" within a single context; for other meanings and in other contexts
the dependency information is less meaningful. Assigning magical and
mystical powers to dependencies elevates them to an importance far
beyond reality.
The same can be said for the instructions in the files being laid down.
Should we provide options so that bpatch or elfedit can be automatically
run on all binaries since the publisher's concept of "working" was so
parochial?
Dependencies are metadata that should be used as input to a policy.
That the default policy is "track and install dependencies" is entirely
reasonable; in fact I would be astonished for anyone to think that's not
a reasonable default. In other circumstances, different policies may be
more suitable.
Administrators seeking to redesign packages to better match their
notion of an ideal distribution should republish the packages
to match their requirements; of course, the results will not likely
be supported by the originators of those packages.
Is this always going to be the answer - to tell us not to use what's
been provided because it's unsuitable and tell us to roll our own?
If you wish to use the bits being provided as a series of hints as to
how to construct your own system, feel free. The packaging system
is designed to install packages as designed. If you feel that the
client packaging system should also support packaging editing (which
is what omitting dependencies really becomes), we have a difference
of opinion.
Installing packages w/o dependencies is like installing a package w/
arbitrary files omitted. The packaging system is not about installing
broken packages... If you want to remove dependencies, files, or other
package contents, republish the package, and accept that you now own
it.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
