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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This would probably be best if we invoked systemctl in the compose
tooling, but at the moment we don't have any execution of target code
on the host. It's fine to assume that it's in /usr/lib.
We can revisit this if we start doing chrooted/containerized
execution.
"atomic rebase" is mostly a copy of "ostree admin switch", so let's
also pick up the changes in ostree admin switch for the new
unconfigured state flag.
This allows a user to "atomic rebase" on an unconfigured system.
Related: #31
For the test suite, we're doing an upgrade offline of another OS root.
What we should maybe do is print the package diff from the merge
deployment, if not the booted one.
However, I think this is OK for now.
Some downstreams want the ability to separate the compose tooling from
the client, for e.g. support reasons.
This approach supports generating a tarball without the source for the
compose command, and requires specifying a config option to disable
it.
Since the treefile format now supports includes, we would need to
either include the whole chain, or just the expanded portion we use in
the compose. This patch does the latter.
This should allow a client to take the same treefile and generate a
similar tree (if they want to reproduce with the same RPMs, those can
be extracted from the RPM database inside the tree).
This improves on the check-diff option by only downloading the
/usr/share/rpm directory to do a package diff. This prevents downloading
the whole deployment and the necessity to do a cleanup later.
As a developer, a workflow I have for testing things is to create
an RPM, toss it into a local yum repository, then do a compose.
However at the moment to add the local overrides I have to edit the
treefile, which is annoying. Let's add a commandline override for
this.
Note this also deletes the old "repos_data" code which was not being
used.
In 827e711 we stopped running two yum transactions. This means the
code that detects if the repodir exists in the yum installroot will
always return false and the code is dead.
These match OSTree. There are a variety of use cases here. One is
for test suites; we can stand up a temporary sysroot directory, and
operate on content inside there.
Another is doing virtual machine upgrades offline from a host system,
or upgrading a different OS.
The duplication here is a bit unfortunate; if we add a lot more
commands we should revisit this and perhaps have a common option
group.
I'm working on a patch to add --sysroot support, and for testing
OSTree stuff I often work from a "traditional" host workstation, and
then I have OSTree content in /.
This makes "atomic status" just work for that; I simply have no booted
deployment.
API probably needs to move to ostree library. Allows us to get a "list"
of REFSPECs, Eg.
"<newest>..<oldest>"
...as a REFSPEC will turn into a list of all the commits, inclusive.
It currently has the following sub-commands:
diff COMMIT COMMIT
for rpmtree diff.
list [prefix...] COMMIT...
for "yum list" like command.
version COMMIT...
for "yum version" like command.
...bunch of FIXME's, UI output isn't great, needs docs.
We also don't use the same code as the treediff on upgrade atm.
I had an epiphany today while working on
https://bugzilla.redhat.com/show_bug.cgi?id=1098304 - I realized that
I can just do an install, and then copy over everything except the
root entries from /etc/passwd into /usr/lib/passwd.
No need for a patched shadow-utils. No need to modify the
/etc/nsswitch.conf before doing the install root. It totally works.
I have no idea why I originally overcomplicated this.
The thing that sucks a bit about this code is that I have to drop to
the FILE * APIs so that I can use the glibc APIs for processing
group/shadow.
Also, the way I deduplicated the code paths for processing
passwd/group is crappy, but I think it's better than duplicating them
(as systemd-sysusers does).
The good: We don't need a two-step RPM transaction, we don't need
a patch for shadow-utils, it's just saner
The bad: Code is not the most beautiful? Not really bad.
The ugly: I didn't think of this in the first place and spent
months beating my head against the wall of shadow-utils...
Per http://fedoraproject.org/wiki/Features/RemoveSETUID
many programs (famously /usr/bin/ping) switched to using
"file capabilities" instead of setuid.
rpm-ostree had code to specially handle SELinux labels, but was
discarding other xattrs. Let's just whitelist reading in
security.capability.
Closes#14
