Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

usability improvement: browsable history #558

Open
dustymabe opened this issue Jan 3, 2017 · 2 comments
Open

usability improvement: browsable history #558

dustymabe opened this issue Jan 3, 2017 · 2 comments

Comments

@dustymabe
Copy link
Member

as a user of rpm-ostree it would be great to be able to seamlessly browse history and inspect the contents of that history in a similar way that you can with git. There are some differences between what I am referring to and the way that git works. With git, the entire repo is local and you can easily browse the diffs between commits etc.. With rpm-ostree I suggest that the thing that we make browsable is the rpm history.

I think we can achieve this goal if we add, in a predictable format, the list of rpms in that commit to the commit log message. ostree need not know anything about rpm if we do it this way. Now that the list of rpms would be in the log message we could just make rpm-ostree read those log messages and make a browsable history.

rpm-ostree log aabbcceeff --> shows date of compose and list of rpms, if the commit does not have metadata that exists on the system, then pull that metadata automatically.

rpm-ostree db diff aabbcceeff gghhiijjkkll --> uses the actual rpm db if those two commits exist on the system, otherwise pulls rpm info from the commit message. if one of the commits does not have metadata that exists on the system, then pull that metadata automatically.

rpm-ostree log --contains docker-9.12.4 --> shows all commits that have this version of docker

rpm-ostree log --rpm docker --> shows all commits where the docker version changed and what the version changed to

These are only some ideas about what we can do with this information. I have not given a lot of thought to the example commands above, they can probably be organized better. Also if we add the rpm information to the commit message in a readable form then we would be able to easily have a web front end interface that could query and display this information for users in an interactive way.

@dustymabe
Copy link
Member Author

shamelessly going to copy some commands here for future me to reference:

Get all commit metadata for all commits in the history:

ostree pull --commit-metadata-only --depth=-1 fedora-atomic:fedora-atomic/25/x86_64/docker-host

Get all rpm db data for all commits in the history:

ostree pull --subpath /usr/share/rpm --depth=-1 fedora-atomic:fedora-atomic/25/x86_64/docker-host

Now you can run ostree log fedora-atomic/25/x86_64/docker-host and pick out some commits to compare and then run rpm-ostree db diff COMMIT1 COMMIT2 to compare them.

@cgwalters
Copy link
Member

At a low level, one problem we face is that the ostree-sysroot layer prunes with depth=0 by default. That's come up other places, it's not insurmountable but we'd have to figure out new commands to manage manually fetched history.

Also of course this all intersects with jigdo, where the history would be fetched from the rpm-md. (Actually in a "full" jigdo world the commits wouldn't have parents probably although that's its own whole topic)

jlebon added a commit to jlebon/rpm-ostree that referenced this issue Dec 19, 2017
This is the first step towards unifying how we introspect packages from
a specific commit. We currently do this in three ways: libdnf, librpm,
and now `rpmostree.rpmdb.pkglist`. I'd like to get to a point where we
only have `rpmostree.rpmdb.pkglist` and libdnf, the latter only when
more complex queries are required.

This patch teaches the `db diff` command to make use of the new db diff
API so that it can work even on metadata-only commits. This is relevant
for use cases mentioned in coreos#558.

I didn't get rid of the `rpmhdrs_diff` functions right now because of
the `--changelogs` option: libdnf currently does not expose this, so we
fall back to the previous API in that case. OTOH, I wonder how much it's
actually used in the wild; maybe we could just nix it?
jlebon added a commit to jlebon/rpm-ostree that referenced this issue Dec 20, 2017
This is the first step towards unifying how we introspect packages from
a specific commit. We currently do this in three ways: libdnf, librpm,
and now `rpmostree.rpmdb.pkglist`. I'd like to get to a point where we
only have `rpmostree.rpmdb.pkglist` and libdnf, the latter only when
more complex queries are required.

This patch teaches the `db diff` command to make use of the new db diff
API so that it can work even on metadata-only commits. This is relevant
for use cases mentioned in coreos#558.

I didn't get rid of the `rpmhdrs_diff` functions right now because of
the `--changelogs` option: libdnf currently does not expose this, so we
fall back to the previous API in that case. OTOH, I wonder how much it's
actually used in the wild; maybe we could just nix it?
rh-atomic-bot pushed a commit that referenced this issue Dec 30, 2017
This is the first step towards unifying how we introspect packages from
a specific commit. We currently do this in three ways: libdnf, librpm,
and now `rpmostree.rpmdb.pkglist`. I'd like to get to a point where we
only have `rpmostree.rpmdb.pkglist` and libdnf, the latter only when
more complex queries are required.

This patch teaches the `db diff` command to make use of the new db diff
API so that it can work even on metadata-only commits. This is relevant
for use cases mentioned in #558.

I didn't get rid of the `rpmhdrs_diff` functions right now because of
the `--changelogs` option: libdnf currently does not expose this, so we
fall back to the previous API in that case. OTOH, I wonder how much it's
actually used in the wild; maybe we could just nix it?

Closes: #1162
Approved by: cgwalters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants