Mailinglist Archive: opensuse-softwaremgmt (14 mails)

< Previous Next >
Re: [softwaremgmt] YUM patterns metadata
  • From: Michael Matz <matz@xxxxxxx>
  • Date: Tue, 22 May 2007 17:03:28 +0200 (CEST)
  • Message-id: <Pine.LNX.4.64.0705221645570.20395@xxxxxxxxxxxxx>
Hi,

On Tue, 22 May 2007, Duncan Mac-Vicar Prett wrote:

> A set of requires, force you to have certain software installed.
> 
> A patch is a policy, a rule. If you apply the policy cert-issue-2889 the 
> rule s that you have to have apache > xy installed, this is a rule, but 
> it is enforced via dependencies.

I can see that, but IMO that's taking the abstraction too far.  Following 
that path also normal packages are "rules", and dependencies between 
packages then too.  It's also useless abstraction, because you don't gain 
anything by naming dependencies rules.  You can simply speak about 
dependencies and everyone will know what is meant.

> Dependencies are the implementation, but on the highlevel, patterns and 
> patches are just a set of rules you want to enforce on a system while 
> the rule is "installed" (or "applied", and get notified when these rules 
> are broken by any reason.

For patches the classification as rules is already problematic: they don't 
consist just of dependencies, they also consist of explicit file change 
sets.  Speaking of them as policies would IMO abstract too far away from 
what patches really are.

<meta topic=abstraction>
Such abstraction is called for when confusion arises about what important 
commonalities of different things are.  But if there's no confusion (and 
if there only three or four thing, we talked only about two actually, 
patches and patterns, there shouldn't be any confusion that dependencies 
are an important common property between them) abstraction just adds bloat 
and actually creates confusion.
</meta>

> > As you said, you also implement languages as such rpm.  You would need 
> > to implement all resolvables as rpms.  For patterns as patches that is 
> > indeed the natural way.  I'm not sure what other Kinds you have.  For 
> > instance what's a language Kind?  Anyway, it would have had quite some 
> > advantages to leverage rpms for all these kinds.  Not the least of 
> > them being to be able to see very easily what patches and patterns 
> > (and other kinds) you actually have installed, and being able to 
> > uninstall them easily.
> 
> Yes, it is certainly possible. But only via conventions (name the 
> patches patch-* and patterns pattern-* for example)

For example.  They could even Provide: some special strings, (like 
"Provide: pattern") so that you can still name them to your liking.  But I 
would actually have loved such convention.

> > I don't see the connection at all.  What's rules about Patterns or 
> > Patches?  Patterns are dependencies and patches are sets of file 
> > changes.
> 
> No, both are just a bunch of dependencies to pull more resolvables after 
> you install them.

Well, seeing it from one angle (the implementation), yes.  But in my mind 
patches not only consist of the set of dependencies, but also of the 
immediate deps itself (or rather also of the differences between the 
installed stuff and the new version, no matter if those differences 
actually exist as delta rpm or if they exist only conceptually).  So my 
mental model of patches is a blob of dependencies and some file deltas, 
where the file deltas is the more important part.  But I guess it's not 
important how my mental model is.  It doesn't help nor hinder their 
implementation as actual rpms.


Ciao,
Michael.
-- 
To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-softwaremgmt+help@xxxxxxxxxxxx

< Previous Next >