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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It's pretty trivial to map a previously existing commit tree into a
mutable tree too. While we're here change the command line arguments
for commit so that we can now properly overlay any combination of
directory, commit, or tarfile.
Rather than offering high level "commit directory", instead perform
operations on a mtree. Commits are treated more like regular objects.
Change the commit builtin to drive this all at a lower level.
The tar import code forced the resuscitation of a hackish "FileTree"
data type for representing an in-memory tree. Split this out
into an OstreeMutableTree class for future use by any other in-memory
tree construction.
Add a simple KEY=VALUE metadata file format, and rather than
assuming 'basename' at a low level, allow passing e.g. NAME=gtk3
to override "gtk+".
The wrapper scripts are annoying...for now let's just remove them.
A regular libfoo.so not in one of the regular directories should go in
runtime. (Probably we should double check it's a regular file too).
Also, delete .la files unconditionally.
ostbuild will generate two artifacts: foo-runtime.tar.gz and
foo-devel.tar.gz in the general case. When committing to the devel
tree, it'd be lame (i.e. slower and not atomic) to have to commit
twice.
One thing that made this take significantly longer than it might
have otherwise is that we have to keep PWD "up to date" - otherwise
we hit bugs in glibc's getcwd() implementation.
This will allow us to have hardlink checkouts of archives. A key use
case here is an archive repo of an OS (with root-owned files etc.)
where we want to do builds in a user tree.
A positive side effect of doing things this way is that now the SHA256
checksums for a given file should be identical regardless of whether
it's stored in an archive or bare repository.
It's too confusing that we call the mode "archive" but the actual
files ".packfile". Also, git already has a "packfile" that serves a
totally different purpose.
To use CLONE_NEWPID we have to actually call clone() because it's
not supported by unshare().
To enable CLONE_NEWPID to be useful, we have to allow creating a new
proc mount rather than binding an existing one.
