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
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 > |