[zypp-devel] patches, atoms, and the delta and patch RPMs in metadata (YUM)
Hi hackers, while redesigning various parts of libzypp a question has been raised about incosistencies/misdesign we currently have in our YUM metadata extensions and ZYpp regarding patches. INTRO: In metadata, a patch includes atoms: element atoms { (element-package | element-script | element-message)+ }+ and the package element is an extension of a normal yum:package: element-package = element yum:package { package & element-pkgfiles & (element license-to-confirm { localized-string }?) } where pkgfiles are the delta, patch or plain rpm file data. In libzypp, delta and patch rpms are appended to Package which, basically represents a plain rpm package resolvable. The rest of the /patch/atoms/package data is an Atom resolvable (with its own dependencies), a helper resolvable used to resolve patch dependencies. PROBLEMS: Well, for me as writer of the new YUMParser it is just a question of mapping the data to classes in libzypp (ResolvableData). Experienced zypp hackers can add more... SUGGESTIONS: ? Attaching current version of patch.rnc and patch.rng for convenience. See also: http://en.opensuse.org/Libzypp/Patches/Rationale http://en.opensuse.org/Libzypp/Metadata/repomd/patches (not very informative today, but will be expanded) Cheers, Jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
In metadata, a patch includes atoms: element atoms { (element-package | element-script | element-message)+ }+
the atom tag is basically to say: In addition to build the patch components, you should "screen" them creating a intermediate resolvable called atom, which depends on the resolvables. and make the patch only depend on the atoms. This is basically a hack for freshens. (conditonal dependencies)
and the package element is an extension of a normal yum:package: element-package = element yum:package { package & element-pkgfiles & (element license-to-confirm { localized-string }?) }
This is wrong. It is just missdesign. We have packages listed both in primary and in the patch itself. What do we do? - we parse primary and built a map of the package identities. - we read the patch package metadata, but we use only the attributes needed to identify them, and create atoms, we look for the packages in the map of packages created during parsing primary, and make the atoms depend on those packages. So the whole package metadata in patches is _useless_. For scripts and messages it does make sense, as they are part of the patch, and they are not present in other parts of the metadata. For packages, only the needed data to identify the package should be needed. Enough to build a dependency that match that package. This remembers us, we need to have checksum and vendor dependencies soon.
where pkgfiles are the delta, patch or plain rpm file data.
In libzypp, delta and patch rpms are appended to Package which, basically represents a plain rpm package resolvable. The rest of the /patch/atoms/package data is an Atom resolvable (with its own dependencies), a helper resolvable used to resolve patch dependencies.
Also is not needed. deltarpms and patchrpms have enough data to be matched aganst a package that could use them for installation. It is not needed to have this metadata inside the package metadata, there could be a complete separate delta & patch rpm index. They are only used on commit.
Well, for me as writer of the new YUMParser it is just a question of mapping the data to classes in libzypp (ResolvableData). Experienced zypp hackers can add more...
I think it only depends if we want to clean this stuff now. I think it is the right moment to do it. But we would need some inter-team coordination zypp-autobuild-maintainance
Attaching current version of patch.rnc and patch.rng for convenience. See also: http://en.opensuse.org/Libzypp/Patches/Rationale http://en.opensuse.org/Libzypp/Metadata/repomd/patches (not very informative today, but will be expanded)
Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Dňa Pi 18. Máj 2007 14:53 Duncan Mac-Vicar Prett napísal:
In metadata, a patch includes atoms: element atoms { (element-package | element-script | element-message)+ }+
the atom tag is basically to say: In addition to build the patch components, you should "screen" them creating a intermediate resolvable called atom, which depends on the resolvables. and make the patch only depend on the atoms. This is basically a hack for freshens. (conditonal dependencies)
The plan is to drop atoms in future, correct?
and the package element is an extension of a normal yum:package: element-package = element yum:package { package & element-pkgfiles & (element license-to-confirm { localized-string }?) }
This is wrong. It is just missdesign. We have packages listed both in primary and in the patch itself. What do we do?
- we parse primary and built a map of the package identities. - we read the patch package metadata, but we use only the attributes needed to identify them, and create atoms, we look for the packages in the map of packages created during parsing primary, and make the atoms depend on those packages. So the whole package metadata in patches is _useless_.
For scripts and messages it does make sense, as they are part of the patch, and they are not present in other parts of the metadata.
For packages, only the needed data to identify the package should be needed. Enough to build a dependency that match that package. This remembers us, we need to have checksum and vendor dependencies soon.
where pkgfiles are the delta, patch or plain rpm file data.
In libzypp, delta and patch rpms are appended to Package which, basically represents a plain rpm package resolvable. The rest of the /patch/atoms/package data is an Atom resolvable (with its own dependencies), a helper resolvable used to resolve patch dependencies.
Also is not needed. deltarpms and patchrpms have enough data to be matched aganst a package that could use them for installation. It is not needed to have this metadata inside the package metadata, there could be a complete separate delta & patch rpm index. They are only used on commit.
Well, for me as writer of the new YUMParser it is just a question of mapping the data to classes in libzypp (ResolvableData). Experienced zypp hackers can add more...
I think it only depends if we want to clean this stuff now. I think it is the right moment to do it. But we would need some inter-team coordination zypp-autobuild-maintainance
Exactly. I'd suggest to keep the focus on the issues we agreed to address in this round. I understand this means refactor this particular piece again, but I'm afraid this would disctract us and in the end might mean not being able to deliver in time. Stano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
* Stanislav Visnovsky
Dňa Pi 18. Máj 2007 14:53 Duncan Mac-Vicar Prett napísal:
In metadata, a patch includes atoms: element atoms { (element-package | element-script | element-message)+ }+
the atom tag is basically to say: In addition to build the patch components, you should "screen" them creating a intermediate resolvable called atom, which depends on the resolvables. and make the patch only depend on the atoms. This is basically a hack for freshens. (conditonal dependencies)
The plan is to drop atoms in future, correct?
YES. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (4)
-
Duncan Mac-Vicar Prett -
Jan Kupec -
Klaus Kaempf -
Stanislav Visnovsky