[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: new tags for RPM



On Wed, Nov 29, 2000 at 11:29:40AM -0500, Alfredo Kengi Kojima wrote:
> 

Lest my remarks below sound harsh, let me preface with a couple of
philosophical comments. Adding tags to rpm is really, really easy. Inventing
uses for new tags is only a tad harder. I'm not opposed to either, but
I need to be convinced that it's the Right Thing To Do.

And, please realize that I may simply add the tags in the interest of
expediting a common rpm/dpkg package format, but that's a whole
different, knottier,  discussion.

> 
> There are some tags lacking from the current
> RPM implementations that would be interesting
> to have, especially for use by tools such as
> APT:
> 
> RPMTAG_ESSENTIAL - a boolean flag telling whether this
> package is essential for the system to be bootable/usable
> (like glibc, bash etc)  Removal of packages with this
> flag could be denied without the --force or equivalent
> option... or not, dunno.
> 

This tag has not clear semantics. Terms like "essential", "bootable",
and "usable" indicate the intent but depend too much on the system
context to be defined precisely.

Adding more implicit overrides to --force is dangerous, as it depends on
a deep understanding of all possible contexts in which the option might
apply (IMHO, --force is evil, but necessary in the real world). Adding a
finer grained override, like --ignoreessential, obfuscates an already
overly complicated API in rpm for little gain.

More generally, packages are not essential to anything other than
package management. Think cellophane, not meat. Marking a package "essential"
to the booting of a system is just plain wrong, as computers need software,
not packages, to boot.

OTOH, marking a file like /bin/sh or /sbin/lilo "essential" to booting
seems more natural, at least to me. Marking an soname like "libc.so.6"
as "essential" is another possible generalization. I can even envision
an attribute "essential" that, when applied to a file like /bin/sh,
is inherited by all prerequisites of the file (N.B. file prerequisites,
not package prerequisites, no way to do this at the moment).

I'd suggest imbuing dependencies with an "essential" attribute, rather
than simply adding Yet Another Tag to packages. That also has a more
natural metric -- weighted count of number of other objects that require a
given object -- something like "essential" strength ... hmmmm.

> RPMTAG_IMPORTANCE - tells how important the package is,
> in the same fashion as dpkg's Priority tag. Values for
> it could be numerical constants, like:
> RPMIMPORT_IMPORTANT 5
> RPMIMPORT_REQUIRED  4
> RPMIMPORT_STANDARD  3
> RPMIMPORT_OPTIONAL  2
> RPMIMPORT_EXTRA     1
> 

This tag has no semantics at all. Who decides what is important?
Where and how can the implicit ordering of relative "importance"
ever be reliably used?

OK, I really do understand that there's a need to establish better
policies for choosing what packages to install, and certainly
"importance" is a step in that direction. However, the world
of rpm lacks the administration policies and authority to
force a single reliable metric for "importance" that dpkg
(with Debian administration) has. Adding the mechanism of
the tag without first establishing the administrative policies
and authority seems premature (to me at least).

> RPMTAG_SUGGESTEDNAMES - a list of package names that are
> considered usefull to have whenever you have this package
> installed. Like xmms-skins when you have xmms installed or
> something like that.
> 

This tag (and dpkg's ENHANCES tag) are used by dpkg to discover
other packages that might be included when upgrading a given
package.

First of all, rpm is missing one of SUGGESTS/ENHANCES, dunno which is which,
but one of them is missing in rpm functionality. <shrug>

Package discovery is crucially important to package management, so
important that I believe that the implementation should not be in
packages at all.

Basically, the issue is legacy. Any information stored in packages starts
to go stale the moment a package is released. And, because packages are
digitally signed and have MD5 sums stored outside of packing, there is no
way to freshen the "stale"-ness of legacy packes. Adding "stale" (i.e.
unreliable) information to packages for the purposes of discovery seems
futile.

IMHO a better approach is to capture package metadata in a format (like
an rpm database or ...) so that the information can be maintained and
updated, as reliability is at least as important a criteria as availability
of information used for discovery.

> Note that rpm will not need to do any treatment over these
> flags, other than just storing them in the package header.
> Therefore, no compatibility will be broken. If you think
> such additional tags are acceptable for a future rpm
> release, I'd be glad to send a patch.
> 

If you send me a patch, I'll add under an #ifdef. However, I'm not convinced
that any of this mechanism belongs in rpm as distributed at this time.

Feel free to argue :-)

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@jbj.org	(jbj@redhat.com)
Chapel Hill, NC





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []