Page 3 of 3

Re: Submitting packages

Posted: 19. May 2016, 18:24
by gapan
Of course.

Re: Submitting packages

Posted: 20. May 2016, 11:32
by Papasot
Several packages I tried built, with gcc 5.3.0, do run on systems with gcc 4.8.2 installed, and vice versa. I have also downloaded the latest version, gcc 6.1.0, and executables built with it do run on Salix 14.1. I even tried programs using new features of gcc 6.x, not supported in previous versions. The execulable is still running without any problem, apparently because of the optimization.

Still, a package for 14.2 should be compiled and linked with the native compiler for 14.2. So I downloaded both the 32 and 64 bit versions of 14.2 alpha1, and using them for the packages submitted.

Newer package versions than the ones instaled.

Posted: 31. Oct 2016, 20:19
by Papasot
Dear developers,
I am responsible for the worker package see, e.g., here for the 64-bit version), which also has avfs as a dependency. Both packages are provided in the Salix 14.2 repository (package versions 3.8.3 and 1.0.3, respectively). The corresponding SBo packages are older than those, so basically useless.

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. So if that's out of question, a problem arises:
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?

Re: Submitting packages

Posted: 2. Nov 2016, 16:23
by maximus
Hi!
See here:
https://docs.salixos.org/wiki/Package_m ... e_packages

EDIT: Although I am not involved with development, if I remember correctly, if a package is a bugfix it is not necessarily excluded from being updated in the repos. In this case I would imagine you need to submit a ticket in the bugtracker.

Re: Newer package versions than the ones instaled.

Posted: 3. Nov 2016, 10:13
by gapan
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.
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: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?
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?

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.

Re: Submitting packages

Posted: 3. Nov 2016, 11:06
by Papasot
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.
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.)
Lesson learned: I'll be sending Salix tickets for package upgrades only if there are indeed security issues or critical bugs, solved in newer versions.
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?
Makes perfect sense to me.
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.
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.
Thank you gapan - once again, you covered my questions and suggested the ideal solution to my "problem".
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.

Edit: Instructions on how to create a local custom repository can be found here.