| Age | Commit message (Collapse) | Author |
|---|
|
|
|
I don't like how much longer this is than the Makefile, but most of it is
option parsing and usage text.
|
|
https://labs.parabola.nu/issues/487
|
|
|
|
|
|
|
|
There are two downsizes to using sed; it line-buffers, and (the existing
pattern) doesn't handle '\r'.
So, now I've included a Perl helper program to do a better job.
I'd originally written it in C, and while that version was faster (the Perl
version stutters occasionally), it required recompilation for different
architectures. I could have gotten around that with tcc, but I didn't want
to add any dependencies. Which is why I settled on Perl. It's part of
group=(base), and it is required by packages in group=(base-devel), so I
can count on it always being there.
It doesn't handle every movement character, just '\n' and '\r', but that's
enough for curl and pacman.
|
|
|
|
|
|
User-facing changes:
- libremessages: `lock_open_write` became `lock`
- libremessages: `lock_open_read` became `slock`
- librechroot: learned the `-r` and `-w` flags to do bind mounts.
Internal changes:
The changes to librechroot were pretty straight-forward; the biggest
change is that `archroot` got split into `mkarchroot` and
`arch-nspawn`.
libremakepkg got a major overhaul Honestly, the changes to
libremakepklg probably could have been a lot smaller, but... I wanted
to do it right/be clean. makechrootpkg in devtools got cleaned up a
lot, actually a lot of the same changes I was making. But, the small
differences between the way we did things made it less than simple to
adjust. The biggest changes in terms of conflict for me are how
devtools now uses bind-mounts to put files in the chroot, and that the
/chrootbuild file is more complicated.
I handled a lot of the complexity by moving things out of the main
program, and adding hooks for non-core functionality, including
chcleanup, distcc compatability hacks, and PKGBUILD/pkg checking.
Unfortunately, the files containing the hooks are currently
hard-coded. Perhaps they will be truly pluggable in the future. That
might be neat. Or over-complicated. We'll see where it goes.
|
|
|
|
chroot-tools
|
|
|
|
I did this by making the assumption that the files in a directory are
dividable into 2 groups: those that are executable, and those that aren't, and
that all of the files in each group all go in the same folder when
installed.
These install directories are configurable per source directory with
$(libre_execdir) and $(libre_datadir)
|
