The package manager currently passes $DESTDIR to the script as $1. There is the ability and possibility to pass other useful information.

Ideas:

• The package's version.
  • This currently involves parsing the version file by finding it through $0.

-> find . -name build -exec grep /version {} +
./extra/cmake/build:IFS=. read -r ver1 ver2 _ < "${0%/*}/version"
./extra/shared-mime-info/build:read -r version _ < "${0%/*}/version"

• The system's triplet.
  • This currently involves running cc.
  • Also allows for easy removal of hard-coded triplets.
  • Could possibly make builds for other architectures easier(?)

-> find . -name build -exec grep -e "cc -dumpmachine" -e linux-musl {} +
./testing/rust/build:build = "x86_64-unknown-linux-musl"
./testing/rust/build:host = [ "x86_64-unknown-linux-musl" ]
./testing/rust/build:target = [ "x86_64-unknown-linux-musl" ]
./testing/rust/build:[target.x86_64-unknown-linux-musl]
./testing/gcc/build:    --build=x86_64-pc-linux-musl
./extra/rust/build:build = "x86_64-unknown-linux-musl"
./extra/rust/build:host = [ "x86_64-unknown-linux-musl" ]
./extra/rust/build:target = [ "x86_64-unknown-linux-musl" ]
./extra/rust/build:[target.x86_64-unknown-linux-musl]
./extra/ccache/build:triplet=$(cc -dumpmachine)
./extra/llvm/build:    -DLLVM_HOST_TRIPLE="$(cc -dumpmachine)" \
./extra/cryptsetup/build:machine=$(cc -dumpmachine)
./core/binutils/build:    --build=x86_64-pc-linux-musl \
./core/binutils/build:    --host=x86_64-pc-linux-musl \
./core/gcc/build:    --build=x86_64-pc-linux-musl

• ???

Take this screenshot:

kiss parses the argument oniguruma and assumes it is kiss o/aka kiss owns.

I actually meant to run kiss i oniguruma. In this circumstance, kiss should catch that I supplied an invalid command (kiss [b|c|d|i|l|r|s|u]) and should print something like kiss oniguruma is not a valid command.

Issue

Sometimes the package manager adds an empty line on depends, even when depends doesn't exist at all.

-> gmake Checking for missing dependencies
--- depends
+++ depends-new
@@ -0,0 +1 @@
+

-> pigz Checking for missing dependencies
--- depends
+++ depends-new
@@ -1 +1,2 @@
+
 zlib

How to reproduce

Build a random package, in my case, it's GNU make and pigz.

Logs:

• https://termbin.com/puta (GNU make, set -x -- what an unfortunate link)
• https://termbin.com/yugl (pigz, set -x)
• https://termbin.com/p8gs (pigz, set +x)

Packages are currently built inside build and installed to pkg. This will break things if kiss is called twice. We can alleviate this by making these directories unique.

kiss a busybox /usr/bin/tar
-> Swapping '/usr/bin/tar' from 'sbase' to 'busybox'
Password:
usage: su [-lp] [username]

Here's a novel idea. Pretty print the package manager output and send all human readable, non-parse-able output to stderr. Then send all parse-able output to stdout. This would allow scripts to be written to interface with kiss while still allowing pretty output for people to read.

This funcion runs as a sub-shell to avoid having to 'cd' back to the

• Detach kiss from the repository location.
• Proper dependency resolver.
• Add $PATH like variable for repositories.
• Write documentation for setup.

From now all commits to the kisslinux repositories are signed. This is further enforced by GitHub using branch protections to deny any unsigned commits.

On kiss update a git fetch and git merge --verify-signatures will be done in place of git pull. This only allows a merge of remote changes if

1. commits are signed.
2. commits can be verified.

Signing will also be an opt-in feature to begin. This allows a testing period for existing users with an easy method of reverting back to the current update process.

I'm leaning towards this being the default afterwards though I'm still thinking about it.

Hurdles to overcome before this will reach users:

• Issue 1: This can't be implemented for at the very least two weeks. 'git merge --verify-signatures' aborts since there's a mix of signed/unsigned commits so it'll take some time until all present unsigned commits have been pulled by users.

  • Ugly solution: Go back and sign every commit in the repository.
    • Can this be done without destroying the current history?
  • SOLVED, users can opt-in now.

• Issue 2: Detecting whether or not the repository should have signatures verified (ie a user repository not signing commits).

  • Possible solution: Check git log --show-signature for the presence of signed commits.
  • SOLVED through the user setting git config merge.verifySignatures true.

• Issue 3: Handling the import and trust of the public key.

  • SOLVED through the user manually importing and trusting the key.

Notes:

• gnupg1 can be installed by default in new KISS installs.

  • Requires no additional dependencies (KISS includes them all in the base).
  • Is still fine for use (source).

    • GnuPG 1.4 ("classic") will stay for embedded and server usage, as it brings less dependencies and smaller binaries. Earlier, it was often installed as gpg, today it is more often named gpg1 (depending on distribution).

Issue

After #93, if the command passwd -l root (by root of course) is issued, the package manager will break since no password will be accepted. Alternative commands should be available in such cases.

How to reproduce

1. As root, do passwd -l root.
2. Run any kiss command as usual.

Hi
I created a package. In the Manifest and in the archive file i see the path i want:
/usr/share/emacs/26.1/etc/charsets/

But kiss doesnt install it. In the source of kiss i found:
rsync --chown=root:root -WhHKa --no-compress "$1" --exclude etc
So i think, thats a bug?

Hello,

Trying to use efibootmgr to boot a stub kernel, I found that the efivarfs was not mounted in /sys/firmware/efivars. I was able to simply execute mount -t efivarfs none /sys/firmware/efi/efivars/ and everything worked as expected.

Not sure if this would go against the philosophy of the manager, but I'm sure that it would be more practical to have a sort of -p/--pull or -s/--sync flag for kiss update.

Naturally, this would iterate through all repositories in $KISS_PATH.

The downside is that a git output won't look necessarily pretty, which makes me curious about an alternative progress bar or something that would make it nicer in terms of UI.

Just a thought, I understand if it isn't necessary.
-v

curl will always be available as the package manager depends on git for updates which pulls in curl. This will fix an issue when swapping to another coreutils where wget is unavailable.

Because it's easy to accidentally input enter multiple times (keyboard repeat, parkinson's), most tools who prompt the user have cancel be the default option. I think it would be better to use the more "standard" ... (y/N)? instead.

The current function is definitely cute with it's 2 lines but doing yes/No is quite trivial too. Maybe something like:

prompt() {
    [ -t 0 ] || return

    while :; do
        log "$* (y/N)? "
        read -r reply
        case $reply in
            [yY]|[yY][eE][sS]) return 0 ;;
            [nN]|[nN][oO]|'') return 1 ;;  # we could also exit() here I guess
        esac
    done
}

...

[ $# -gt 1 ] && {
    prompt "Install built packages [$*]" && {
        args i "$@"
        return
    }
    exit $?
}

Okay, I was testing "util-linux", packaged it, compiled it, installed it all without error, using the following commit a-schaefers/community@9648b16

The only depp I specified was "make", and it won't let me kiss r util-linux, it returns:

util-linux Package is required by 'e2fsprogs', 'eudev', 'gdk-pixbuf', 'glib', 'gtk+2', 'libSM', 'libXmu', 'libXt', 'python'

AND to top it all off, I can't find the package installed where I specified in the build file, /opt/util-linux doesn't exist.

What just happened?

Sorry if this is a wrong place to ask, but it seems that I cannot find this in the documentation.

Is it possible to specify a version (or version range) for a given package dependency? If not, how do you envision to deal with cases when packages X and Y both depend on Z, but X only works with versions (>= 1.5 and < 2.5), and Y with versions (>= 2.0 and < 3.0)?

If a package that contains /usr/bin/tar is removed (in the "default" case, busybox), then kiss won't be able to proceed to the next step as tar doesn't even exist.

When I type "kiss b" or "kiss b foo bar" I want the option to keep going when a build fails, attempting to build as many things as possible, and at the end 1. offer to install the packages that did build (as normal) and 2. to display which packages failed, if any did fail. Gentoo's emerge has this option and it is quite handy. Thanks

Looking at your code in kiss, I wonder if it wouldn't be more effective to use something like uextract to split out the source package to workable code.

To quote the author 'SFR' :"In order to ease unpacking of various archive formats, I forged One Script to Rule Them All (well, at least most of them Wink ). "

Especially since uextract can work with command lines the likes of >

uextract -o /root/somedir archive.tar.gz arch2.7z somepkg.rpm

UExtract will automatically make use of the following tools, when available:

7z
aescrypt
ar
arj
avconv/ffmpeg
balz
base64
bbb
blkar
bcrypt
brotli
b(un)zip2
c1541
ccrypt
cpio
cryptsetup
dar
ddjvu
dpkg-deb
dzip
exploderpm
extract_chmLib
extract-ikconfig
fdisk
flzp
fossil
fp8
fusecompress_offline
gdisk
gifsicle
gostcrypt
gpg/gpg2
gs
g(un)zip
kgb
ha
hexbin
icotool
innoextract
lbrate
lepton
lha
lizard
losetup
lpaq1
lpaq8
lr(un)zip
lz4
lz4jsoncat
lzfse
lzip
msgunfmt
nanozip
nomarch
nulib
paq8l
paq8n
paq8o
pdfdetach
pdfimages
pdftocairo
pdftohtml
pdftotext
php
poweriso
qemu-nbd
quad
ripmime
rpm2cpio
r(un)zip
scrypt
snzip
sqlite3
steghide
swfextract
tar
tnef
tor
tosz
truecrypt
unace
unalz
(un)arc
(un)asd
(un)compress
uncpk
undms
unegg
(un)freeze
(un)lzma
(un)lzop
unlzx
unp64
unpack200
(un)rar
unsquashfs
(un)xz
unzip
upx
uudecode
veracrypt
wvunpack
xar
xcur2png
xxdecode
zimdump
zoo
zpaq
zstd
zxing
zzip

Supported, though not extensively tested at this point, formats/extensions are:

.??_ .2fs .3fs .3gp .4fs .7z .7z.001 .7zip .a .a[0-9][0-9] .a2theme .ace .acp .adz .aes .ai .alz .amf .ani .apk .aplp .app .appimage .apz .ar .arc .arj .Arch00 .arduboy .ark .asc .asd .au .avastsounds .avi .azw2 .b64 .baklz4 .balz .bau .bbb .bdoc .bfe .bgz .bin .blend .bmp .bmz .br .bxy .bz .bz2 .bzip .bzip2 .cab .capx .cb7 .cba .cbr .cbt .cbz .cdmtz .cdmz .cfs .cgz .chm .chrt .cld .cpgz .cpio .cpio.7z .cpio.br .cpio.bz .cpio.bz2 .cpio.bzip .cpio.bzip2 .cpio.f .cpio.gz .cpio.gzip .cpio.lrz .cpio.lz .cpio.lz4 .cpio.lzma .cpio.lzo .cpio.xz .cpio.z .cpio.zip .cpio.zst .cpk .cpl .cpt .cramfs .crf .crx .ctb .ctx .ctz .cur .cvd .cxarchive .d64 .d81 .daa .dar .dat .dazip .db .db3 .dbk .deb .depot.gz .dia .disk .divx .djvu .dll .dmg .dms .docx .dotx .dsk .dsl .dz .ear .eaz .ecs .ecsbx .efossil .eftx .egg .emerald .eml .emz .eopkg .epk .epub .esriaddin .exe .ext2 .ext3 .ext4 .f .f3d .f3z .fat .fb2k-component .fcstd .flac .flf .flp .flv .flzp .fossil .fp8 .fsl .fwp .fzbz .fzpz .fzz .g3x .gadget .gc .gem .gg .gif .gifar .gmz .gnumeric .gnutar .goomod .gpg .gps .graphmlz .gst .gszip .gtar .gtp .gz .gz2 .gzi .gzip .ha .hc .hfs .hfv .hid .hme .hmxz .hqx .htmlz .htz .hwp .i5z .iar .icl .ico .igz .ima .img .imz .ip .ipa .ipcc .ipg .ipk .ipsw .iso .ita .itz .iwd .ja .jar .jgz .jic .jpeg .jpg .jsonlz4 .kfo .kgb .kmz .kpr .ksf .ksp .kwd .lbr .lca .lemon .lep .lha .libzip .little .liz .lnx .love .lpaq1 .lpaq8 .lpk .lpkg .lrz .lxf .lz .lz4 .lza .lzfse .lzh .lzm .lzma .lzo .lzx .maff .mar .mbox .mbz .mcgame .mct .mcworld .mdf .mds .mdz .mdzip .mga .mht .mhtml .mim .mime .mkv .mmip .mo .mov .mozlz4 .mp3 .mp4 .mpeg .mpg .mpk .mpkg .mpz .mpzip .mscz .msg .msi .msp .msu .mxl .mzp .mzz .nbf .nbm .ndr .nex .nfl .ngr .nif .nlr .nrg .nsis .ntfs .nth .nupkg .nz .oar .obt .odb .odc .odf .odg .odi .odm .odp .ods .odt .oex .ogg .ogv .ogz .onepkg .opk .orb .otg .oth .otp .ots .ott .ova .ovp .oxt .p2s .p2a.backup .pack .package .pak .paq8l .paq8n .paq8o .par .pat .pax .pbi .pbp .pcv .pdf .pet .pfs .pgp .phar .pigm .pigs .pisi .piz .pk3 .pk4 .pkg .pmlz .png .potx .pptx .prg .psz .pup .pvga .pxz .qch .qcow .qcow2 .qcow2c .qpk .qpr .qtz .quad .quiz .r[0-9] .r[0-9][0-9] .rar .rar5 .ReaperThemeZip .rmskin .rp9 .rpm .rsn .rub .run .rz .s3z .safariextz .sam .sar .sb .sbx .scm .scr .sdi .sdk .sdz .sfe .sfg .sfs .sfx .sh2 .sh3d .sh3f .sh3t .shar .shk .shr .sifz .sle .slm .slp .smzip .snap .snappy .snz .sob .sox .spack .spk .spm .sqf .sqfs .sqlar .sqlite .sqlite3 .sqsh .squashfs .srm .stc .std .sti .stpZ .studyarch .stw .styx .sublime-package .sue .svgz .swf .swm .sxc .sxd .sxg .sxi .sxm .sxw .sys .sz .tar .tar.7z .tar.br .tar.bz .tar.bz2 .tar.bzip .tar.bzip2 .tardist .tar.f .tar.gz .tar.gz2 .tar.gzip .tar.lrz .tar.lz .tar.lz4 .tar.lzma .tar.lzo .tar.md5 .tar.xz .tarz .tar.z .tar.zip .tar.zst .taz .tazpkg .tb2 .tbz .tbz2 .tc .tce .tcel .tcem .tcx .tcz .tg .tgz .themepack .thm .thmx .tlrz .tlz .tlz4 .tlzma .tnef .tor .tpkg .tpxz .ts .tsk .twz .twzip .txz .tz .tzma .tzo .tzst .u .u3p .uax .udeb .udf .unitypackage .upx .usfs .ustar .utz .uu .uue .vbox-extpack .vc .vdi .vfd .vgz .vhd .vmdk .vmg .vob .vpk .wa .wal .war .wav .wba .wbm .webm .webz .wgt .wgz .whl .widget .wim .wlz .wma .wmd .wmga .wmv .wmz .wot .wrz .wsp .wsz .wv .x3d .xap .xapk .xar .xbps .xcfbz2 .xcfgz .xjt .xjtbz2 .xjtgz .xlam .xlsm .xlsx .xltx .xmcdz .xmz .xo .xpi .xrns .xsn .xwp .xx .xxe .xz .xzm .Z .z .z[0-9][0-9] .zab .zabw .zad .zds .zfsendtotarget .zi .zi_ .zim .zip .zipx .zl .zlib .zm9 .zoo .zpaq .zpi .zst .ztd .zxp .zz

and there is a simple drag-n-drop gui also available when a window system is running.

There's an equivelent called "packit" to go the other way.

We use it extensively in puppylinux.

UExtract contains the following translations:

• Polish (SFR)
• Russian (Sender & Pro)
• German (L18L)
• Spanish (nilsonmorales & vicmz) [needs updating]
• French (Argolance)
• Dutch (foxpup)
  And English of course

This is our link, http://www.murga-linux.com/puppy/viewtopic.php?t=87864

We do have other ways of unpacking multiple sources by using case statements, but this is the easiest to use nowadays,

just a thought

So sbase find is quite problematic. I have checked the manpage and I don't see an entry about -mindepth and -maxdepth. Those might not be POSIX.

-> Resolving dependencies
find: paths must precede expression: -mindepth
!> Package 'sbase' not in any repository

This fixes issues when upgrading packages and ensures that upgrades happen in the correct order. This may or may not be an issue.

Current status

Kiss has post-install files that allow the package to run a script that sets it up right after installation.

Rationale

Some packages, such as shells, might need to clean up the system after being uninstalled (removing their entry in /etc/shells).
Adding and removing system users for various services (ssh, http, ftp) also comes to mind.

Proposal

Additional Pre/Post Install/Uninstall/Upgrade scripts.
This can be implemented through either separate files, like the current post-install,
or a central scripts or install file with multiple functions.

1:

• Doesn't break existing packages.
• Causes fragmentation.

2:

• Will break existing packages relying on post-install.
• Limitation to shell scripts. This can be mitigated by passing the function to be run as an argument.

An extension of this would be also passing the package version strings to functions, for ex. if a package only needs to run the upgrade steps between specific versions (this, and the second approach, are inspired by Arch PKGBUILDs).

When building a new, empty KISS_ROOT (e.g. /kiss, henceforth referred to as "target"), the package manager should not check the make dependencies in the target kiss database (e.g. /kiss/var/db/kiss), but only check the make dependencies in the old root with a full KISS environment (e.g. / with database in /var/db/kiss, henceforth referred to as "host"). Since when building target we're using binaries from the host, any make dependencies from the target KISS_ROOT won't be used.

However, if the host is not a kiss system, we would have to rely on their packaging system (e.g. I had to use apk from Alpine to install m4 for bison makedepends)

I am using kiss 0.5.9-1 (from kisslinux/repo/releases/tag/0.0.18-musl).

Take this screenshot:

If kiss search py* returns python-setuptools, it should also return python.
If kiss search py doesn't return anything, then kiss search py* should also return nothing.

We should standardize how kiss searches for packages. I would expect all 3 searches to return the same packages:

kiss search py
kiss search py*
kiss search python
# => python-setuptools, python

We could also have an --exact flag, a la:

$ kiss search --exact python-setuptools # => python-setuptools

Edit: Add kiss version
Edit: Actually, the --exact flag may add unnecessary complexity to the package manager. Keeping the KISS Linux projects' APIs small is a project priority.

Rationale

In a system, we can have multiple implementations of a program, simple example: vi, which can mean either vim (/usr/bin/vi symlinked to /usr/bin/vim) or busybox (/usr/bin/vi symlinked to /usr/bin/busybox). Alternatives system will be needed, in particular, to resolve conflicts between multiple implementations (if any).

Proposal

Packages can have an alternatives file. However these are to be installed to /var/db/kiss/alternatives. The directory structure would be something like this

/var/db/kiss/alternatives
├ vi        # (group)
│ ├ busybox # (package)
│ └ vim     # (package)
└ sh        # (group)
  ├ dash    # (package)
  ├ bash    # (package)
  └ busybox # (package)

Of course, the manifest in the respective packages will be updated to reflect this.

The busybox file in vi group directory would contain something like this:

busybox usr/bin/vi
busybox.1 usr/share/man/man1/vi.1

Where $1 is SOURCE and $2 is TARGET, much like a regular ln operation. Note the lack of leading /, since $2 will be ${KISS_ROOT}/$2. This can contain multiple symlinks, in case of multiple binaries, manpages and/or libraries.

When an "alternative" is selected, the contents will be the source and target for ln operations.

Also, we can add an operation kiss alternatives, something like this:

vi:
- busybox*
- vim
sh:
- bash
- busybox
- dash*

This is still a very rough concept, so if anyone has any questions/critiques, please state it.

It has come to my attention that kiss is designed in mind to be run not by root, but a regular user, and asks your sudo or su password. If you don't have sudo, you'll have to enter your password every single time, unless you su to root and try to build everything as root. The downside to building everything as the root user is that some packages will fail to configure as root without passing the allow unsafe environment variable to configure first.

I was thinking we could solve it by having root pass off the whole thing to a privileged user such as "kiss". This is all a little above my paygrade probably, but just throwing it out there as a suggestion to somebody more capable than I am in shell scripting.

Correct me if I am wrong, but it would be nice if we built using chroots so that we could figure out explicitly what depends we need to build stuff, thusly making more trusty build files for everybody.

This bug only really surfaced now due to most testing being done in the chroot. Installation and removal of package requires root by design. This bug concerns package building, downloading etc.

Causes

• /var/cache/kiss and /var/db/kiss/ have insufficient permissions for non-root.

This can either be done through a conflicts file or we can recursively check each manifest file in /var/db/kiss and abort on error during pkg_install.

Personally I'd like to go with the second option as it requires nothing in the repository.

Issue

Self-explanatory. In my case, the package involved is clang and my own llvm-unified trial package.

How to reproduce

While my llvm-unified is installed, install clang. It doesn't warn of conflicts, but it does warn of llvm not being installed, which means the first check fails to do its job.

My llvm-unified build script is available upon request.

Build log

KISS clang manifest
My llvm-unified manifest

Hi,

to write some packages I downloaded the installation file kiss-chroot.tar.xz and decompress it on /mnt/kiss. My goal is to test the build of packages and to not forget dependencies. So I chroot to /mnt/kiss and there I can try to build the package. For zathura I discovered for example that the dependency gtk+3 was missing. It was already installed on my system, so I forgot the dependency.

The "problem" is: after building a package, I have to remove everything to test another one. I thought I could write what was installed, but I discovered it doesn't work, there is too much work. I still have to think about it, but do you have an idea what could be done ? A new feature for kiss or for kiss-utils ?

I tested the distribution Nutyx and such a mechanism exists. The package manager for Nutyx is cards. With:

cards create -r mypackage

the system is restored to the same after a fresh installation and the package mypackage is installed. So we can't miss a dependency. The idea is to build in a chroot.

I don't know if I want this feature to be added. The package manager will need a rather large rewrite to allow multiple packages to be built/installed at once.

Instead a simple wrapper script can fill this niche.

I need option like --quiet-build in emerge or something like that
I need to hide any build (and install) output, except fail log
for example
export KISSFLAGS="--quiet-fail"
https://dev.gentoo.org/~zmedico/portage/doc/man/emerge.1.html

--quiet-build [ y | n ]
    Redirect all build output to logs alone, and do not display it on stdout. If a build failure occurs for a single package, the build log will be automatically displayed on stdout (unless the --quiet-fail option is enabled). If there are multiple build failures (due to options like --keep-going or --jobs), then the content of the log files will not be displayed, and instead the paths of the log files will be displayed together with the corresponding die messages. Note that interactive packages currently force all build output to be displayed on stdout. This issue can be temporarily avoided by specifying --accept-properties=-interactive. Further, note that disabling --quiet-build has no effect if --jobs is set to anything higher than 1. 
--quiet-fail [ y | n ]
    Suppresses display of the build log on stdout when build output is hidden due to options such as --jobs, --quiet, or --quiet-build. Only the die message and the path of the build log will be displayed on stdout. 

When building more than a few packages, there is no real way of keeping track of the progress. Sometimes it's possible to figure out the current package from the compiler output, but there is no convenient way of knowing if the current package is the 5th or very last one in the queue (besides remembering the order).

It would be nice if kiss displayed the current package number together with the total amount of packages to build. Given that the total amount of packages is available as $# in pkg_build() and only a counter, keeping track of the current package number, would have to be added, it seems trivial to implement.

I would definitely change the output in build_pkg() to someting like [foo] Starting build 4 of 10. Additionally, the terminal title could be set using the OSC escape sequence \e]0;foobar\a. The latter would be nice but is not supported by all terminals, so I'm not sure what to do with it. Without terminal titles, one could simply redirect the output of kiss to a file and then lookup the build status there. As an alternative to setting the terminal title, something like gentoos --quiet-build option could be explored.

I'm willing to implement that feature myself but wanted to first get some input on the whole idea and the different options.

When bootstrapping baselayout, I realized something is wrong with the directories, specifically /root and /tmp, since their permissions should be 0750 and 1777 but both are 0755.

Tracking the pkg_install process, I found this, perhaps this is the offending command since it creates the directory using default permissions.

Since in theory (and actually, in practice!) it's actually possible to use symlinks in place of actual files to use some of the main repo's files like sources and versions to the package metadata dir since I'm too lazy to modify the file myself if there's an updateto increase efficiency so I can change only what's needed and follow upstream (in this case, kisslinux/repo). This is one of the main advantage of KISS' packaging model I can exploit.

This, however, creates problems if the package is installed, since the symlink would be preserved.

Example (my busybox installed, ls -l $pkg_db/busybox)

-rwxr-xr-x    1 root     root          1300 Oct 22 08:16 build
[...]
-rw-r--r--    1 root     root          4691 Oct 22 08:16 manifest
lrwxrwxrwx    1 root     root            38 Oct 22 08:16 sources -> /var/db/kiss/repo/core/busybox/sources
lrwxrwxrwx    1 root     root            38 Oct 22 08:16 version -> /var/db/kiss/repo/core/busybox/version

It would be great to see the metadata resolved and have the actual file/directory and its contents packaged instead of the symlink (we should limit it to just the files in $pkg_dir/$pkg_db, since having an intentionally-created dangling symlinks (e.g. the runit service script in the busybox build file) "resolved" would be problematic, to say the least).

KISS_CHOICE=1 kiss i sbase ubase
kiss i busybox 

results in busybox overwriting sbase/ubase without warning of conflict / requiring KISS_CHOICE=1 for the busybox install command.

This means that next time busybox is updated, then sbase or ubase will be purged from a user's system.

Is there further steps required for a migration towards sbase/ubase and away from busybox, or is this a bug?

Thanks