<ioraff>
but if a package that provides it isn't installed, the pm won't know what dependency to resolve
<illiliti>
then it's up to user which package to install to satisfy dependency
phinxy has quit [Quit: WeeChat 3.5-dev]
phinxy has joined #kisslinux
<illiliti>
we could also include manifests into repo to automate that
<illiliti>
or leave a comment to suggest which dependency to install
<illiliti>
/usr/lib/libLLVM.so make # llvm, llvm-fat
<midfavila>
if the manifests were included, that could work
<midfavila>
otherwise I fail to see how it would be an improvement over the current system
<ioraff>
manifests won't be constant until the package manager sandboxes builds
<ioraff>
even so, a manifest could be different under a different version of a package in the build environment
<illiliti>
fair, let's proceed to another option
<illiliti>
what about symlinks? has anyone tried to implement provides using them?
<ioraff>
what do you mean?
<illiliti>
pkg -> llvm(symlink) -> llvm-fat
<illiliti>
pkg depends file: llvm make
<illiliti>
after build is complete, we could change llvm to llvm-fat in depends file
chomwitt has quit [Ping timeout: 268 seconds]
<illiliti>
so /var/db/kiss/installed/pkg/depends will have: llvm-fat make
<illiliti>
or just keep: llvm make
<illiliti>
i didn't measure which one is better
<illiliti>
we would need a new tool to control symlinks though
<illiliti>
actually provides is possible already via abusing KISS_PATH and repos
<illiliti>
but it isn't great
<ioraff>
I feel a provides file is still the best option. seems the most flexible and least opaque
<illiliti>
yeah
<illiliti>
i'm just looking at other options to make sure we didn't miss anything
fitrh has joined #kisslinux
<illiliti>
how kiss supposed to choose "provided" dependency if there are many of them?
<illiliti>
if prompt - i don't like it
<illiliti>
priority? i suspect that would make logic more complicated
<ioraff>
I had only imagined a prompt. priority wouldn't let the pm be agnostic about package names, and has the possibility of packages claiming the same priority.
<illiliti>
prompt sucks
<illiliti>
i'd rather bail out and let user decide which dependency to install
<ioraff>
that's functionally equivalent to a prompt. x package needs y -> pm lists all the packages in KISS_PATH that provide y -> prompt for which to install or exit and have the user manually install one.
<illiliti>
yeah but without input parsing nonsense
<illiliti>
if we could make it a simple Y/N, then ok
<illiliti>
we also have KISS_PROMPT. we should respect it somehow
<ioraff>
it'd just be parsing a number. I wonder how every other distro that has a similar function determines what package is the default.
<illiliti>
priority, as far as i'm aware
<illiliti>
no other way
<illiliti>
if multiple packages have same priority then abort()
<illiliti>
any other options?
ella-0 has joined #kisslinux
ella-0_ has quit [Read error: Connection reset by peer]
fitrh has quit [Remote host closed the connection]
fitrh has joined #kisslinux
<testuser[m]1>
Hi
<virutalmachineus>
hi
<ioraff>
hi
fitrh has quit [Remote host closed the connection]
<testuser[m]1>
illiliti: how is priority decided
rohan has joined #kisslinux
rohan has quit [Ping timeout: 244 seconds]
rohan has joined #kisslinux
rohan has quit [Ping timeout: 260 seconds]
rohan has joined #kisslinux
<testuser[m]1>
Also we should prompt to rebuild every package that depends on the provider that has been changed
<testuser[m]1>
wait no
<testuser[m]1>
yea
<testuser[m]1>
no
<ioraff>
no
<virutalmachineus>
but why not!!!
<virutalmachineus>
my CPU is idle everyday, it needs a workout once in a while.
<virutalmachineus>
My CPU needs to be in tip top shape when I need to compile chromium.
<virutalmachineus>
getting the CPU warmup can increase performance by 0.00843%
<wael[m]>
is there a tool that can automatically fill in the commit message for a kiss package update/new ?
<wael[m]>
eg kiss commit <package> and it automatically adds the package and does the commit message on if its a new or a update
<illiliti>
we can reserve second field for priority
<illiliti>
i.e: <name> <uint>
<illiliti>
package with higher number has higher priority
<illiliti>
based on that we reorder "provided" dependencies
<illiliti>
if user has set KISS_PROMPT, package with highest priority will be default
midfavila has quit [Quit: Leaving.]
<illiliti>
KISS_PROMPT=0 to be exact
midfavila has joined #kisslinux
<testuser[m]1>
Where is the priority field going to be set and how would it make sense for independent repos
<illiliti>
in provides file
<illiliti>
what is independent repo
<testuser[m]1>
Repo doesn't have knowledge of other repo
<testuser[m]1>
llvm-fat provides file would have `llvm 2`
<testuser[m]1>
llvm-superfat would have .
<midfavila>
>mfw github requires JS to access release tarballs now
<illiliti>
soydevs don't have anything better to do than reworking ui it seems
<midfavila>
fortunately you can access releases in plaintext using https://github.com/$AUTHOR/releases/expanded_assets/$RELTAG
<midfavila>
well, not plaintext, but minimally formatted HTML
<illiliti>
llvm-superfat would have: llvm 1 ?
<illiliti>
llvm-sane would have: llvm 3
<illiliti>
what problem are you implying?
<testuser[m]1>
I mean if u have llvm in main repo, llvm-fat in some zig repo, llvm-superfat in some $LANG repo and each repo is maintained by different authors
<testuser[m]1>
how would they set propriety
<testuser[m]1>
priority
<testuser[m]1>
Also what does a priority greater than 2 mean
<testuser[m]1>
It's either sane package or modified package
midfavila has quit [Remote host closed the connection]
midfavila has joined #kisslinux
<illiliti>
well, some coordination would be required
<illiliti>
and IMHO must not have same priority
<illiliti>
packages*
<illiliti>
values of priority have no special meaning
<illiliti>
so if modified package has 4, i.e highest priority, then it will be default1
<illiliti>
same if package has 400 priority
<illiliti>
it doesn't matter
<illiliti>
we could reserve 0 for something special, but i don't know for what
<testuser[m]1>
What about just making automatic decision based on repo priority
<testuser[m]1>
Or better just error out if kiss prompt is set and print msg to `kiss select llvm llvm-fat` or something
<illiliti>
yeah, that's my first thought
<testuser[m]1>
erroring out is appropriate according to kiss ideas stuff should be explicit
<illiliti>
> What about just making automatic decision based on repo priority
<illiliti>
that's how people implement provides right now
<illiliti>
KISS_PATH="./modified:./orig"
<illiliti>
kiss b pkg will take llvm from modified
<illiliti>
reorder KISS_PATH and you have provides system
<illiliti>
but as i said it isn't that great
<illiliti>
there are some limitations
<testuser[m]1>
What do u think about the erroring out idea
<testuser[m]1>
For me erroring > decision on repo priority > priority system
<illiliti>
it's fine
Beni has joined #kisslinux
midfavila has quit [Remote host closed the connection]
midfavila has joined #kisslinux
fitrh has quit [Remote host closed the connection]
an3223_ has quit [Remote host closed the connection]