search

kisslinux / kiss

KISS Linux - Package Manager
https://kisslinux.github.io
MIT License
464 stars 62 forks source link

Feature request - comparing package versions with those further down the KISS_PATH #263

Closed LostGhost1 closed 3 years ago

LostGhost1 commented 3 years ago

Say I have a custom repository, where I override packages from some other repository, with some super-special compilation flags, for example, and this repository is first (or in front of the other repository anyway) in the KISS_PATH. After a time, a package in the other repository updates, but because I have a custom repo, I don't get notified in any way.

There are three ways this could be dealt with:

  1. Periodically manually check all repositories packages from which I override
  2. Add functionality to the package manager, which, when the "kiss update" command is issued, after searching through repositories in KISS_PATH and finding the packages up for an update, doesn't stop its search, goes further down KISS_PATH, compares version numbers from packages in these repositories with the ones found initially, and notifies the user "hey, repository that you are overriding has a fresher package version". This solution would slow down the package manager and add complexity to it.
  3. Implement the logic described above as a separate tool or add it to kiss-outdated

I prefer the third solution and like the idea of implementing it myself, however, I feel like my bash skills aren't up to the task. What do you think, dylan?

dylanaraps commented 3 years ago

The package manager (and package system) make no attempt (by design) to compare version numbers beyond basic equality (ver1 == ver2). There is no concept of "newer than", "older than", etc. The first result in KISS_PATH is considered the "latest version" and an update to a package is triggered when the aforementioned equality check (between the install package and repository package) fails.

In other words, this feature cannot be implemented as the true "latest version" is unknown.

I suggest you go with 1. and keep track of development to these repositories. 3. is also an option if a tool were to be made.

Thanks for opening this issue.

dilyn-corner commented 3 years ago

kiss-link is basically the solution you want anyways

LostGhost1 commented 3 years ago

kiss-link is basically the solution you want anyways

In the situation that I described, how would kiss-link help? Could you explain it in detail please, because I don't fully get what kiss-link does

LostGhost1 commented 3 years ago

@dylanaraps Well, that will complicate things. And yeah, every piece of software has its own convention when it comes to version numbering. However, we only have to compare different versions of the same software, which can't be too difficult, can it? Yeah, I'll have to do some thinking about this. I can see myself writing a tool like this in C.

dilyn-corner commented 3 years ago

kiss-link is basically the solution you want anyways

In the situation that I described, how would kiss-link help? Could you explain it in detail please, because I don't fully get what kiss-link does

You don't need to compare the version strings of the same package later on in KISS_PATH when you just say 'this version should always be considered as the version of this one'.

If all you want to do to a package is alter the build script, the dependencies, patches, files, or sources, then you just need to use kiss-link to symlink the version of your forked package to the other package. Now your updates will happen in the way you're suggesting. ETA assuming you're making use of the new feature where VERSION in sources is replaced by the contents of the version file.