Mailinglist Archive: opensuse-factory (765 mails)

< Previous Next >
Re: [opensuse-factory] Announcing Tumbleweed Snapshots: Rolling With You
  • From: Jimmy Berry <jimmy@xxxxxxxxxxxxxxx>
  • Date: Fri, 24 Nov 2017 17:21:42 -0600
  • Message-id: <CABTDdhVAj+vW+TBz4fyiwdfx=2Z9iY72jVpC3b7dgu-BhOOh2g@mail.gmail.com>
On Thu, Nov 23, 2017 at 3:15 AM, Richard Biener <rguenther@xxxxxxx> wrote:
On Wed, 22 Nov 2017, Jimmy Berry wrote:
So the issue is that somebody (for example packagekit) does a refresh
on the repo file and not that the mirrors purge old rpms referenced
from older meta data, right? To me it sounds you want to "pin" metadata
instead? What happens to security updates in this case?

Pinning metadata is not terribly useful if the referenced rpms are not
available in the remote repo. Security updates remain unchanged. The
update repo (for urgent security fixes) is already iffy depending on
which snapshot you have installed and it is not snapshotted in anyway
by my tool. As such the behavior should be the same as default setup.

I suppose the way we organize repository meta-data is less than
optimal here. With updated metadata I suppose you can't even
do a zypper in glibc-2.22-4.9.1.x86_64 with a version from an
earlier snapshot.

That is, we'd need repo metadata that covers the full state of
the download area, thus reflecting what you can actually install?
And zypper having multiple version choices for a specific package
could be asked to do a "minimal" install that requires the least
number of packages to update but by default would prefer the
newest version.

Such repo data might be huge of course and we might be too aggressive
in pruning old binary rpms from the download area and thus making
old repodata invalid fast.

Indeed. Having to download such a large amount of meta data, depending
on how far back is available just to see the current state seems
rather suboptimal. Creating the "merged metadata" and then managing
the rpms based on it does not seem beneficial. From the user stand
point they simply want to install the new package that was built for
their current install. If they want everything updated then they
should update.

This implementation preserves full meta data sets for each snapshot
and keeps all the relevant rpms. As such you simply point the repo URL
at the snapshot you have installed or want to install and zypper
operates normally. The default setup (depending on what changes are in
newer snapshots) is basically like running Leap 42.3 with your repos
pointed at 15.0 and installing kate. That may or may not end well. The
expected behavior there would be to dup to 15.0 and then install kate.
Rather than expect that users dup every day this allows users to
update at their own pace, but still install things as needed.

Your idea about asking zypper to install with "minimal change" seems
like a similar concept, but would require further investigation and
implementation. This approach would appear simpler and operates
transparently as if they are "mini-ephemeral-static distros" which are
just historical Tumbleweed snapshots. Purely to allow a user to keep
using the snapshot which they have installed since installing new
packages essentially built for a "different" distro is less than
ideal. Basically, users are in two modes: I want to update to latest,
or I just want to install this new thing. This allows those mental
modes to map to reality just like they did prior to rolling release.

Depending on the way the rpm requirements are setup I've seen
installing a new application trigger partial qt or kde updates that
create an unusable desktop (even X fail to start). Short of some
serious changes to spec file policies and tooling this seems like the
only sane solution.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >