Re: Submitting packages
Posted: 19. May 2016, 18:24
Of course.
Are there any security issues/critical bugs with the previous packages? If not, then there is little reason to upgrade the packages in the repositories.Papasot wrote:Now, worker's developer already has a new version for both packages, which I was able to compile without using anything else but the tools Salix's normal static repository provides (gcc and other dependencies.) I actually made a new SLKBUILD for those, uninstalled old versions and installed the new ones with sudo installpkg. I see no reason why those new versions cannot replace the older, already outdated ones, in Salix repository. Newer versions of said packages don't really affect anything else in the system (no other packages in Salix repo depend on those). However, I realize that officially replacing existing packages in Salix repository is against Salix's (and Slackware's) philosophy.
First of all, whatever is included in the repositories is by default considered the better version (not necessarily newer), that's why you're always "upgrading" to that. There is no sense comparing version numbers because there exists no algorithm that can accurately compare two versions in all cases. Sure, "2.1" is most probably newer than "2.0", but which one is newer, "3.6.2" or "neon.1"? "0.4" or "A.1.3"? "45.4.0esr" or "46.1.0"? And what happens if a package does indeed get upgraded to a new version in the repositories, but sometime later a critical bug/security issue is found with the newer version and we replace it with the older one which had no such problems? Wouldn't you want the package management system to "upgrade" you to the older version?Papasot wrote:If I try to do a system update and upgrade, gslapt says package worker 3.8.4-x86-64-1pp should be "upgraded" to worker 3.8.3-x86-64-1pp, and package avfs 1.0.4-x86-64-1pp should be "upgraded" to avfs 1.0.3-x86-64-1pp. This is clearly downgrading instead of upgrading. Note that the above is just an example: a similar problem arises when I upgrade, e.g., library glfw with the newest version (which, by the way, not only improves the one Salix repository provides, but also fixes some bugs.) I am really not sure Salix repository provides a more "stable" version of those packages. Actually, the opposite is true. The only reason Salix repository provides the older versions is that I submitted those when Salix 14.2 was still in beta stage, because they were the latest "stable" versions back then..
Anyway, to avoid downgrading of the above packages each time I update the system, I excluded those packages in gslapt's preferences. However, I expected the system to consider those packages as newer (as their version says) and let them intact, instead of trying to downgrade them to Salix's repository versions. Is there any way to do that, or I should just stick with excluding them?
The newest worker package adds a few new features and fixes a (minor and rare) bug. The newest glfw library is merely a bug-fixing release. In both cases, however, there are no serious bugs in Salix repo versions. I tested the newer versions and, although they are definitely better, I understand that replacing the existing ones in Salix repo is basically against Salix philosophy (sounds more like a current Slackware material to me - corresponding packages in Slackel are already upgraded.)gapan wrote:Are there any security issues/critical bugs with the previous packages? If not, then there is little reason to upgrade the packages in the repositories.
Makes perfect sense to me.gapan wrote:First of all, whatever is included in the repositories is by default considered the better version (not necessarily newer), that's why you're always "upgrading" to that. There is no sense comparing version numbers because there exists no algorithm that can accurately compare two versions in all cases. [...] And what happens if a package does indeed get upgraded to a new version in the repositories, but sometime later a critical bug/security issue is found with the newer version and we replace it with the older one which had no such problems? Wouldn't you want the package management system to "upgrade" you to the older version?
The second option seems more "robust" to me (why I didn't think of it myself? ah, because experience on Salix is invaluable, and I'm still learning its small secrets). I added a custom local repo including just the packages I want upgraded, and works like a charm.gapan wrote:If you want to build your own packages and manage them by yourself in your own system without the package management system bugging you about it, you have two options:
1. Excluding them, as you have found out.
2. Creating a local repository with those packages in your HD and adding it to your slapt-getrc with a higher priority (CUSTOM) than all others. You'll only need to keep updating that repository then.
Unfortunately, that wiki webpage doesn't mention the second option. Tried to add this information, but realized wiki does not accept registrations to avoid spammers.maximus wrote:See here:
https://docs.salixos.org/wiki/Package_m ... e_packages.