On Thursday, October 27, 2016 7:11:39 PM CDT Christian Boltz wrote:
Hello,
Am Dienstag, 25. Oktober 2016, 15:05:58 CEST schrieb Jimmy Berry:
In the same way that TW is released in snapshots the repo itself would benefit from being presented by snapshot.
I see what you want, but I doubt the way you want is a good idea ;-)
Having to switch the snapshot repo every two days sounds annoying, so the better solution is probably - keep the rolling repo (as we have it today) - this is what Tumbleweed users will use in 99% of the cases - add a way to switch to a previous repo snapshot (in case someone needs a previous package version) - this could mean running a "zypper ar" command or (more development work) adding some code in zypper to switch to a specific snapshot
Seems people keep missing the part about zypper automatically handling the repo switch (rather simple). It is not just for previous versions of packages as I explained about installing new software after an updated snapshot updates related packages. Please read the whole proposal. The whole idea is that if I am aware of this feature I will probably be someone who will just branch a package and maintain that against current TW until it is resolved (as I and others do regularly). That of course still does not resolve the other issues handled by this. This needs to be automatic so that it works without the user having to know about it. The reason for prefixing the repos is that is works without reworking all of zypper.
Publishing full snapshot repos is probably a nightmare for the mirrors because they would need $snapshot_count * $repo_size of space, which sums up to "a lot" ;-)
This ignores the symlinks to unchanged packages and if several versions of previous packages are already being kept then the mirrors already have $snapshot_count * $repo_size where $snapshot_count is number of old versions kept. Even if we kept the same number of old snapshots this would be a much improved state. People that will know exactly what packages to switch to older ones and how to do that will likely branch and maintain anyway.
AFAIK old packages are already kept in the repo for some days (to avoid breaking it for people in the middle of an upate), but those old packages are not included in the repodata. Actually it even seems the repodata (filelist etc.) for some previous snapshots is kept, but no longer referenced in repomd.xml.
To implement snapshot repos, it should be possible to provide _snapshot repodata_ only, and link to the packages in the rolling repo. Ideally this would mean to only have suse/repodata/ (and possibly some more metatada I overlooked) specific to each snapshot, and all the other directories symlinked to the rolling repo.
This way would have some advantages: - probably easy to implement - not too painful for the mirrors (only some hundred MB of additional metadata)
Plus all the older packages that have to be stored either way (largest part). The only difference then is the symlinks and the directory itself which I would expect to be marginal and does not require any updating to metadata/ versioning. From what I understand this still does not accomplish the goal since the user would have to explicitly switch to older packages and such. I would imagine it would also require download of such meta data for all previous releases since all of them would be in one repo which seems less than ideal especially considering there are already complaints about the size.
- no changes in zypper needed because the rolling repo could stay the default (if you want a previous snapshot, you'll need to "zypper ar" it and disable the rolling repo) - but I won't object if someone wants to implement a command to switch to a specific snapshot
Addressed above, this forces the user to do something in order to use the snapshot repos which partially defeats the point.
Feedback from someone who knows about how the repo is created and published would be nice - I'm especially interested if it's really as easy as a think/hope ;-)
Regards,
Christian Boltz
-- Jimmy