Mailinglist Archive: opensuse-softwaremgmt (14 mails)
| < Previous | Next > |
Re: [softwaremgmt] YUM patterns metadata
- From: Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx>
- Date: Tue, 22 May 2007 15:55:33 +0200
- Message-id: <200705221555.34060.dmacvicar@xxxxxxx>
On Tuesday 22 May 2007 15:02:54 Michael Matz wrote:
> But I actually have another question regarding patterns and how they're
> implemented. I'm sure the original designers thought about it, so please
> explain the reasoning: why are patterns no rpms? It would have made
> everything much easier: you would be able to see which patterns you have
> installed (without support in all tools, just looking at rpm -qa), the
> dependency solver would have been there already, just about everything
> makes rpm a perfect fit for patterns. So why was this funny on-top
> concept invented?
basically all of the concepts could have been implemented as rpms.
Patterns and patches doesnt have any difference. Both are policies. Or a set
of dependencies.
You could in theory create a dummy rpm with no files, that depends/recommends
other packages, and it is named pattern-FOO-X.Y.noarch.rpm.
This only works if all your resolvables are implemented on top of rpms,
because the solver works with something called "Kind" of resolvables.
Dependencies (capabilities) are basically:
deptype: requires, recommends, provides
kind: Package, Pattern, Patch, etc
name, version, architecture, for versioned dependencies.
RPM dependencies assume that kind is "package" because you can only depend on
packages. So you either implement everything as rpms, or only packages. For
patterns, and even patches this could work. But how do you make a pattern
require a language resolvable if the languages are not implemented as rpm?
It would have been worth to explore anyway.
IMHO Patches and Patterns should become policies. They are only rules. You can
categorize the policies in patches and patterns if you want.
--
Duncan Mac-Vicar Prett
Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-softwaremgmt+help@xxxxxxxxxxxx
> But I actually have another question regarding patterns and how they're
> implemented. I'm sure the original designers thought about it, so please
> explain the reasoning: why are patterns no rpms? It would have made
> everything much easier: you would be able to see which patterns you have
> installed (without support in all tools, just looking at rpm -qa), the
> dependency solver would have been there already, just about everything
> makes rpm a perfect fit for patterns. So why was this funny on-top
> concept invented?
basically all of the concepts could have been implemented as rpms.
Patterns and patches doesnt have any difference. Both are policies. Or a set
of dependencies.
You could in theory create a dummy rpm with no files, that depends/recommends
other packages, and it is named pattern-FOO-X.Y.noarch.rpm.
This only works if all your resolvables are implemented on top of rpms,
because the solver works with something called "Kind" of resolvables.
Dependencies (capabilities) are basically:
deptype: requires, recommends, provides
kind: Package, Pattern, Patch, etc
name, version, architecture, for versioned dependencies.
RPM dependencies assume that kind is "package" because you can only depend on
packages. So you either implement everything as rpms, or only packages. For
patterns, and even patches this could work. But how do you make a pattern
require a language resolvable if the languages are not implemented as rpm?
It would have been worth to explore anyway.
IMHO Patches and Patterns should become policies. They are only rules. You can
categorize the policies in patches and patterns if you want.
--
Duncan Mac-Vicar Prett
Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-softwaremgmt+help@xxxxxxxxxxxx
| < Previous | Next > |