Closed dilyn-corner closed 3 years ago
I can reproduce. On it.
Fixed. Thanks for your continued reports.
Let me know if the issue still occurs, I can no longer reproduce.
(Issue was $hash
not being reset between invocations of the sh256 functions)
Is indeed resolved now, thank you sir!
Will push a release shortly.
While I have you, what do you think of this (related to #224)?
KISS_HOOK
.
fossil pull; fossil update
or rsync ...
for example. It's up to them.pre-update
, does a simple test (cmp -s "$0" "${0##*/}"
) (Is the current hook identical to the current repository's hook?) If they are identical, proceed else exit.kiss u
and everything just works. (This is not really a proposal as the mere change to execute hooks in non-Git repositories makes this possible.) Just letting you know this is now a "feature" I guess? :laughing:
Update hooks now fire in non-Git repositories so users are able to implement custom retrieval methods themselves to support whatever they like. Repositories can provide their own hooks to perform remote retrieval. (rsync, zclone, fossil, wget/untar, etc)
I love the idea of this -- part of my interest in this (https://github.com/kiss-community/kiss/commit/e04b26d756566c9b3ea4767c1ce50149d127b4f8) change was so that kiss
wouldn't have to listen to every 'add support for $hypeproject' request and it would instead be on the user (or in this particular case, the maintainer) to be smart about the implementation they choose. It's more in-line with the KISS style IMO.
This does of course bring up the question: what happens to git
support embedded in kiss
? I don't see a particular reason to privilege one repository retrieval method over another if the possibility of an update-hook setting that for us exists. I'm not opposed to the idea of leaving git
support within kiss
itself, but it does become slightly redundant.
This gives a chance to inspect the hook and prevents the hook from being executed just by its mere existence (like the old method we both ended up removing).
Very important. It also means that users aren't forced to stay inline with the repository maintainer just to do updates (though you did allow this in dfd000e9c5b4542191b826d2fff8b4803c402380 which I love).
I think this change is a Good Idea(tm); it's not really burdensome on users - there's... a single extra step for repository maintainers (which they have to do probably just once, if at all), and the requirement for a user is basically equivalent to them checking out the repository in the first place. There's a small amount of friction there, though; perhaps the hook should be enabled by default, or a prompt for users to inspect the hook (print it to stdout
?), possibly the prompt is [Y/n] to enable/disable the hook, and whenever the hook is updated the prompt reappears? This removes any friction for users and is... roughly fool-proof? This of course only makes sense if the hook is bundled with the repo itself.
This does of course bring up the question: what happens to git support embedded in kiss? I don't see a particular reason to privilege one repository retrieval method over another if the possibility of an update-hook setting that for us exists. I'm not opposed to the idea of leaving git support within kiss itself, but it does become slightly redundant.
This is what it looks like: https://github.com/kisslinux/kiss/pull/251
There's a small amount of friction there, though; perhaps the hook should be enabled by default, or a prompt for users to inspect the hook (print it to stdout?), possibly the prompt is [Y/n] to enable/disable the hook, and whenever the hook is updated the prompt reappears?
The idea behind utilizing KISS_HOOK
is that the repository maintainer can name it (and store it) wherever they like. The other queries are in a similar vain to showing a prompt to inspect build
files (which we don't do: ie, it's up to the user).
The package manager doesn't store any kind of persistent state (only downloaded package sources and built binaries) so there's no way for it to know between invocations that a hook file has been inspected.
Anyway... will tinker with this and come up with some kind of one-step process (though I quite like the two-step process regardless).
So I made a pull request for my repos repo to use the new hook system, and had a few questions:
source /etc/profile
line in post-install actually do anything, or is there some sort of exec magic I can do to make it so users don't have to open a new shell after kiss install kiss-repo-jedahan
to have their KISS_PATH working?As far as 'one step process' I think this should work, though I need to test it this week.
This does of course bring up the question: what happens to git support embedded in kiss? I don't see a particular reason to privilege one repository retrieval method over another if the possibility of an update-hook setting that for us exists. I'm not opposed to the idea of leaving git support within kiss itself, but it does become slightly redundant.
This is what it looks like: #251
There's a small amount of friction there, though; perhaps the hook should be enabled by default, or a prompt for users to inspect the hook (print it to stdout?), possibly the prompt is [Y/n] to enable/disable the hook, and whenever the hook is updated the prompt reappears?
The idea behind utilizing
KISS_HOOK
is that the repository maintainer can name it (and store it) wherever they like. The other queries are in a similar vain to showing a prompt to inspectbuild
files (which we don't do: ie, it's up to the user).The package manager doesn't store any kind of persistent state (only downloaded package sources and built binaries) so there's no way for it to know between invocations that a hook file has been inspected.
Anyway... will tinker with this and come up with some kind of one-step process (though I quite like the two-step process regardless).
Please correct me if I am misunderstanding, but I don't think the package manager needs to do anything special regarding tracking state for hooks compared to any other package. If we package hooks, then we can use all the facilities we have for managing system state for free.
Description
Packages which have git+* sources don't have checksums, but
kiss
will abort during the checksum check. However, this ONLY seems to happen in cases where that package 1) has a dependency that isn't already built or installed, and 2) has a source which requires no checksum.All of this is done in a fresh chroot, where
kiss
is latest master.Error message
Verbose log
If I do
kiss b ncurses
and installncurses
first, the build forvim
proceeds as normal.