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@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org