This was half-assed. I'd much prefer we keep things simple and users
use repositories for this purpose. Either full or partial forks. This
is "proper" and stores the build configuration
This is a backwards compatible change. The package manager will
for the time being /ignore/ checksums lines containing Git
repositories.
These aren't checksums and have no business living in the checksums
file. This file is now strictly for checksums. In the coming months,
this special handling will be lifted.
This adds support for both absolute and relative directories in
sources files. Relative file sources have always been supported,
this just extends it to directories.
Absolute paths to directories and files in sources is totally new.
Directories will have their /contents/ copied to the initial build
directory. The second field in the sources file can be used to set
destination location.
Checksums will not be validated for directories of any type. Absolute
file paths do have their checksums validated.
Notes:
The package manager will check to see if the source is a directory
or not. There is no need to have a trailing forward slash (though it
might make sense to enforce this anyway, we'll see).
With this change, checksums generated by the package manager will no
longer contain the second field (the basename of the file). The second
field is quite useless as ordering is already fixed.
This change is backwards compatible and existing checksums files will
containue to function as normal. As checksums are regenerated (with
updates to packages), the new format will be used.
The compatibility works via checking /only the first column/ in each
checksums file. This is the only part of the file which must match
1:1 as ordering is always the same.
Notes about etcsums:
This change also affects the etcsums file which is used for the
3-way checksum verification for files in /etc/.
Existing etcsums will simply be invalidated with the safest path chosen
(.new file is created) until they are regenerated via a package build.
Ordering is now fixed inside etcsums files. This makes parsing them
faster and more reliable.
This also fixes a theoretical bug with naming conflicts during parsing
of etcsums.
The package manager will look for an executable called 'update' in the
repository's root directory. If a KISS repository is one of many
children in a git repository, the hook will only be called once.
This hook is run /after/ a repository has been updated by the package
manager. If your repository is not using git, the hook is run immediately.
If the hook fails (exits non-zero), the package manager will also fail.
Hooks can be written in any language. No arguments are given to the executable.
Closes#174
This is related to the tarball and default repository location
changes which leave KISS_PATH unset /by default/.
There's no real reason for the package manager to die here. When
no repositories are enabled (or no package is found in KISS_PATH),
the package manager uses /var/db/kiss/installed as a fallback.
Related to: https://github.com/kisslinux/repo/issues/209
This replaces the package based exemption with one based on C and
POSIX shared library names, removing the hardcoded reference to
musl and adding support for more C libraries.
This needs testing with non-musl systems. Specifically, the
dependency fixer which runs post-build in 'kiss build' should /not/
display anything related to your C library. If it does, please open
an issue.
These files are unneeded and become a source of errors when an
autotools build references a non-existing .la file. This was the
case with a recent update to freetype-harfbuzz.
The files are required by libtool to do libtool things, however
libtool works just fine without them. These files are safe to
remove according to upstream and other distributions have already
been doing this for a while.
> https://www.gnu.org/software/automake/faq/autotools-faq.html
>
> 3.1 What are these .la files for and can I safely remove them?
>
> portable encoding of static and shared library names and dependencies.
>
> removing usually only works OK if done in directories which the
> runtime linker searches by default anyway (otherwise you might need
> to set LD_LIBRARY_PATH or an equivalent variable) and only on systems
> where the runtime linker loads indirect library dependencies
> automatically (includes GNU/Linux, GNU, Solaris).
It is recommended that you remove all .la files from your system
if manually updating the package manager to the latest version.
Running 'kiss update' will automatically handle this for you.
The following script will be run on post-install to clean up the
.la files. This can also be run manually. Executing this script
will do nothing if the system is already clean.
#!/bin/sh
find "$KISS_ROOT/usr/lib" \
! -type d \
-name \*.la \
-exec rm -f -- {} +
find "$KISS_ROOT/var/db/kiss/installed" \
! -type d \
-name manifest \
-exec sed -i '/.*\.la$/d' {} +
This commit also brings back the removal of charset.alias which was
a part of the default KISS_HOOK prior. It makes much more sense for
it to live alongside this change.
The package manager will no longer clean up any other pre-existing
cache directories at exit.
- Fixes a portability issue by removing usage of /proc.
- Fixes issues when the user has KISS_PID set.
- Outside of the realm of what the utility should do.
This adds support for relative paths when passing tarballs to kiss
directly and removes a prevents a misleading and confusing error
message from appearing (a false 'file not found').
This commit adds KISS_STRIP to allow stripping to be controlled at
runtime for all staged packages. This is also handy when temporarily
needing debugging symbols for a given piece of software.
Defaults to '1', set to '0' to disable stripping.
Example:
KISS_STRIP=0 kiss b zlib
This never truly worked as the post-install message would always
ensure that file size is '> 0' despite there being nothing to show
the user.
We now store the output to a variable, ensure it isn't empty and
go on our merry way.
