On Thu, Mar 13, Duncan Mac-Vicar Prett wrote:
Hi guys, here is the proposal:
we put the .solv file in repodata/something.solv
repomd.xml gets extra data:
<data type="solv"> <location href="repodata/something.solv.gz"/> <checksum type="sha">eed8ddc83f767f5a959b29e3ec006f53a2ab871d</checksum> <timestamp>1205162318</timestamp> <open-checksum type="sha">e837550df577f334d03d71b4bb1218d6b533e1ae</open-checksum> </data>
Advantages: - no need to re-sign the solv file. - we can add version and metadata in the same file.
Version information could be stored as: <data type="solv" format-version="7" schema-version="3">
Cons: - need to modify createrepo, but we already do for patches, if we use createrepo. If not, this is not a cons.
Maybe we can take care the created .solv files conatin disk usage information, even if the plain yum does not support it?
libzypp workflow:
* when probing, probe first for type "solv" (becomes a new type of repos)
I don't see why this should be a new type of repo. It's our extension to yum. If repomd.xml lists usable .solv file we use it, else we use the plain yum data. If there are no yum data in the repo, it's empty then. I don't see why this should be a new type.
* look for repomd.xml, * look if there are solv files * download and unpack * if there are not, fallback to yum (this needs to be evaluated wether it is easy).
That's the YUM type workflow.
For CDs, we can put there a repodata/repomd.xml with the solv file information only.
The SUSETAGS workflow? We have two cases here a) susetags only (suse/setup/descr) b) susetags + embeded yum (suse/setup/descr and suse/repodata) @a) I don't see why we should not list the .solv files directly in the content file? If something changes, the content file has to be updated anyway, because it had to contain the repomd.xml checksum, to be able to monitor changes. So we could as well add the .solv files data directly. We IMO gain nothing. Just introduce another file to check, download and parse in order to retrieve the .solv. @b) If we'd like to use the same .solv files for both, we must ensure the .solve provides enough information. Namely - products and patterns - diskusage info for packages - (maybe something else too) The yum repo at suse/repodata had to be extended to contain products and patterns .xml as well, otherwise .solv file content and yum data as fallback don't fit together. If we do it that way, we may find out that we don't need susetags anymore (at least suse/setup/descr). If we don't, we need a 2nd .solv for susetags, either containing the additional solvables only (product/pattern), or the complete repo (e.g. in case yum .solv files don't provide e.g. disk usage info). This .solv would then be listed in the content file. I'd vote for enhancing the susetags the same way as yum. Let the content file comntain the .solv file definitions. This way we are free to use different sets @b) as long as we need them. Goal could be to work on sharing the .solv files in order to obsolete susetags format. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org