IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We really want people using these trees to know what went in it. If
the tree doesn't actually have /usr/bin/rpm inside it, then do an
"rpm -qa | sort" and dump that into: /usr/share/rpm-manifest.txt
This will help our story with GPL compliance too.
OSTree really wants /var to come empty; it's not going to be practical
to change every RPM right now though. So, let's dynamically turn the
content from /var into systemd-tmpfiles.d snippets.
This allows us to skip the whole install process if the
RPMs haven't changed, which is a rather large win.
Part of this commit involves some code to attempt to talk to "yum
shell" for dependency resolution, in an attempt to avoid depsolving
twice, which just isn't really going to work, since "yum shell" isn't
an API as it turns out.
The only other real alternative is doing something PackageKit-like,
which is ~4000 lines of very nontrivial Python.
There are two major reasons:
1) I want to do things like process SELinux labels here, and that
type of thing is best done in C.
2) There are presently 3 languages in this code, and this takes us
down to just two.
At the moment, a lot of RPM content has files whose content derives
from timestamps (like .pyc files). We really don't need to do another
commit to the repository if it's just these files which changed.
Fix this by caching the package list at the rpm-ostree level, and
don't commit if it hasn't changed.
We're moving more towards the autobuilder model; this allows us to
keep all of the data in one place. Important for the
cloud.fedoraproject.org instance since /mnt/ostree is the large
filesystem.
The two transaction thing is bad for multiple reasons, but what bit me
specifically was something in the group transaction pulling in
'kernel-debug', and then installing 'kernel' later.
