Alexander Eremin wrote:
On Wed, 2009-08-26 at 10:19 +0100, Robert Milkowski wrote:
I'm sorry, but really - the whole discussion has little to do with
technicalities as most of us agree it is possible to implement, the
discussion seems to be more about persuading people who have been
doing
--nodeps like workarounds for years in production that they actually
shouldn't because all packages we (as Sun and community) going to
provide will be perfect and you will never need such a feature, and
if
you need to then write your own tools. I'm sure it will happen at
some
point but really such a feature should be a part of packaging tools
as
it is on most other platforms, at least on one of the most popular
these
days - Linux.
+1
And in addition: --force is often required in daily sysadmin's work
If package A depends on package B, allowing package A to be installed
w/o package B will result in arbitrary breakage. This breakage may
occur at install time if the reason for the dependency is a hardlink,
in which case the installation of package A will fail to complete.
More commonly, however, the breakage will occur during run time,
causing a failure to load a kernel module, failure to exec a program,
or dynamic failures once the program/module is running.
In any case, package A is damaged, and will not behave as tested or
expected. Thus, other packages which depend on A may be broken
as well..
System administrators that use --force are essentially doing ad-hoc
restructuring of the packages on their machine; these packages are
no longer as defined by their publishers, and any signatures on them
are no longer meaningful.
As such, this strikes directly at the design goals of pkg(5) -
installation of the software as per the specifications of the publisher.
What is being asserted here is that some publishers don't do a
satisfactory job of package publication, and that administrators
might be able to better reconfigure the packages to their needs.
Fine.
Pkg(5) already has the needed mechanisms to allow the modification
and republication of existing packages w/o recompilation. This
will allow admins to perform arbitrary modifications to any packages,
including modifications of existing binaries, etc, and these
modifications will be obvious and auditable - pkg verify will be
able to complete successfully and indicate that the system matches
its packaging manifests. This means that the administrator is
explicitly becoming a software publisher, with everything that
means in terms of testing, etc.
What we're NOT willing to do is to allow the ad-hoc editing of
published packages w/o the explict step of the admin owning
the re-publication (and subsequent updating) of those packages.
- Bart
--
Bart Smaalders Solaris Kernel Performance
ba...@cyber.eng.sun.com http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
