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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Let's try out https://wiki.centos.org/ContainerPipeline
Having maintained Docker images for rpm-ostree seems kind of overdue.
(I didn't actually test the CP bits since I'm not sure how to do that)
Closes: #460
Approved by: jlebon
As long as we require uid 0, we should encourage people to run
`compose tree` in its current state inside a Docker/nspawn container.
I didn't spend a lot of time on this yet but it works. Am considering
switching to a CentOS base though.
Closes: #249
Approved by: giuseppe
This is in preparation for `rpm-ostree container`, which handles
unpacking RPMs as non-root.
At the moment, I'm copying code in from both ostree's libarchive bits
(fixable...may need to export some utility functions) and some
functions from libhif (harder, see:
http://lists.rpm.org/pipermail/rpm-ecosystem/2016-January/000297.html )
There's lots more cleanup to do here, but I don't want to block on the
resolution of the libhif changes.
Makefile.dist-packaging seems to assume to be run under packaging/ as
"make -C packaging -f Makefile.dist-packaging rpm" so ensure the
srcdir is set correctly to point to the parent directory.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
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.
This will move to a separate repository. This allows a clearer
separation between the core tool (which is shipped on client systems
too), and the compose infrastructure.
Furthermore, I want to make the autobuilder a Docker container.
This is somewhat similar to what we've been doing with Continuous; we
take the manifest.json, and turn it into a "snapshot". Except here
there is a notion of inheritance.
This gets stored into the tree as /usr/share/rpm-ostree/treefile.json.
Additionally, it goes into the autobuilder directory in
products-built.json. Though really we should split up that file,
since it will be kind of...large.
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.
