[softwaremgmt] YUM patterns metadata
Hi!
(posting also to zypp-devel, but pls. discuss it on opensuse-softwaremgmt)
At http://svn.opensuse.org/svn/zypp/trunk/libzypp/zypp/parser/yum/schema
you can find the current state of patterns metadata schema (patterns.rnc
and rng).
We never used patterns in YUM sources so far, so there is some space to
make changes to it as we need. So please post comments, suggestions.
Multiple pattern*.xml files or a single one?
I have one suggestion to start with: let's keep patterns in one file by
adding
Hi! Dne úterý 22 květen 2007 13:02 Jan Kupec napsal(a):
Hi!
(posting also to zypp-devel, but pls. discuss it on opensuse-softwaremgmt)
At http://svn.opensuse.org/svn/zypp/trunk/libzypp/zypp/parser/yum/schema you can find the current state of patterns metadata schema (patterns.rnc and rng).
We never used patterns in YUM sources so far, so there is some space to make changes to it as we need. So please post comments, suggestions.
Multiple pattern*.xml files or a single one?
I have one suggestion to start with: let's keep patterns in one file by adding
element to encapsulate the <pattern> elements: .... start = element-patterns .... element-patterns = element patterns { pattern+ } ....
I think it makes more sense than having separate file for each pattern (or product), since sources providing patterns are (typically) not used for maintenance and thus no new patterns are appearing during the repository life cycle (which is not true for patches). It also keeps consistence with packages. Jiri
Currently, there would be zero or multiple <data type="patter"> entries in repomd.xml.
BTW: the same question applies to products as well
Cheers,
jano
-- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz
Hi, On Tue, 22 May 2007, Jan Kupec wrote:
Multiple pattern*.xml files or a single one?
Would make sense. But in the light of future extensibility it makes sense to nevertheless allow multiple such description files (each containing a set of patterns). So that you can extend the available set of patterns, should the need arise, you never know, without having to redownload the set of all patterns. 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? Ciao, Michael. -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
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@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
Hi, On Tue, 22 May 2007, Duncan Mac-Vicar Prett wrote:
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.
Yes, (I think "policies" is the wrong word here, policies are sets of rules, not really sets 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.
Exactly.
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?
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.
It would have been worth to explore anyway.
IMHO Patches and Patterns should become policies. They are only rules.
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. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
On Tuesday 22 May 2007 16:26:54 Michael Matz wrote:
Yes, (I think "policies" is the wrong word here, policies are sets of rules, not really sets of dependencies).
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. 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.
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)
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. -- 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@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
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
On Tuesday 22 May 2007 17:03:28 you wrote:
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.
Actually they are just metadata that depends on newer rpms. The fact that some of these rpms can be installed downloading delta/patch rpms is something evaluated at commit time and not at solving time, thus the patch does not need to know about rpms at all, it only need to express which version of a group of packages fixes the problem. The commit logic should grab and rpm and install it, or download a script and run it to patch a binary, or get a delta rpm, or untar something in /. So the file delta is just an implementation detail, but it is not in the patch itself. Note: in our current metadata it is, but just because the patch format is missdesigned. They not need to be there (therefore all packages are duplicated inside the patch and the primary file!!) -- 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@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
participants (4)
-
Duncan Mac-Vicar Prett
-
Jan Kupec
-
Jiri Srain
-
Michael Matz