Difference between upgraded packages and rebuilt packages.
 

Hello all,

I'm tring to further my understanding about Slackware and GNU/Linux in general, so any help with this would be greatly appreciated.

In the 14.2 stable changelog you can see that some packages have been upgraded and some have been rebuilt:

I realize that upgrading can be to add new features but in the context of Slackware is the difference that upgrading is only for security fixes and rebuilding can be for security fixes as well as a bug fix? Isn't the lower level aspects of upgrading and rebuilding the same, it's the motive that differs? For example, both the upgraded package and the rebuilt package both had to be rebuilt. In both scenarios some code was either added or removed or fixed and then the source code was recompiled.

I believe I understand the higher level aspect. A developer of a certain package will release an upgraded version (security update) which then Pat will compile on his own machine then transfer into a Slackware package for us, which we can then install. For rebuilding a package Pat or a user realized that a package has a bug and then Pat corrects it himself, and not the original developer. Then the same process is followed as upgrading i.e. recompiled and transfered into a Slackware package, then made available to us.

I've read (I don't remember where) that rebuilding a package can cause instability in a system and one of the reasons Slackware is stable is packages are only rebuilt when necessary. Whereas some distributions tend to rebuild on a "regular" basis.

The questions I have are:

If what I've wrote about the differences between upgrading and rebuilding is wrong or incomplete, could you explain to me what the differences actually are?

And also, why can rebuilding a package possibly cause instability? Can this also be true for upgrading a package?

Again, any help is greatly appreciated :)

An upgrade is when the version changes. A rebuild is when it is the same version, but it needs to be rebuilt for whatever reason (link against upgraded libraries, changed build flags, change something about the packaging, apply new patches, etc.). There's really not much more to it than that.

Unless the package maintainer screws up or doesn't test thoroughly, there's no inherent reason why rebuilding a package would cause instability. Indeed, in many cases it has to be done for the software to continue functioning. I think maybe what you've heard is that some software is rarely rebuilt simply because it doesn't need to be. I suppose some other distros might rebuild things on a regular basis as a matter of policy. I don't think one approach is necessarily better than the other. It's the level of testing that matters. Things can break due to being rebuilt, but they can also break due to not being rebuilt when they should have been.

Its not necessarily common, but its possible that rebuilding a package after other packages have updated such as gcc or another dependency will expose new issues. I have seen programs entirely break due to obscure gcc regressions in current before.

A rebuilt is also necessary when a shared library is bumped, so it linked against the new version to avoid causing breakage. An upgrade will have the same issue fixed, but not all software have new releases when a shared library is bumped, so a rebuilt is what it needs.

Thank you for your explanations, montagdude!

Okay, so by "when the version changes" you mean the code has been modified. Doesn't applying a patch count as modifying the code, and thus be an upgrade?


This really helped clear things up. It makes sense that if a package works and it's not necessary to rebuild it then just leave it alone, because human error might introduce a problem.

Thank you for your response, orbea!

I looked up gcc regressions. So basically what would happen is a bug in gcc would cause the program to break. A bug that was not present in the version of gcc the program was originally compiled with.

I've also heard that rebuilding software can expose bugs that went undetected previously (from what I remember I think that's how it was put). Is this also what you mean by "expose new issues"?

Thank you willysr, this helped a lot!

Basically, this means whenever the version number changes. Most of the time, this is done by upstream (the developers of that program), when they have made significant enough changes for them to release a new version. The "version number" can also change when Pat uses a specific commit from their git repo. This is more frequently done when they don't provide specific releases or there was a benefit in providing a non-release version of the program (the kernel-firmware package is a great example since it will just package the latest firmware from the kernel's repo -- I don't even know if they provide releases).

If the version number is the same, but the package has been changed (fixing an issue with the SlackBuild or adding a patch) or recompiled (due to dependencies or something similar like the library bumps mentioned earlier), the package is listed as "rebuilt" and the build number will increment by 1 (so the package manager knows the package is different).

In the examples you provided, I've highlighted the build numbers in red:

If Pat were to rebuild python-2.7 for any reason, it would increment the build number to 2, which would make the package be python-2.7.16-x86_64-2_slack14.2.txz and if he were to upgrade infozip to the next version, it would reset the build number to 1, which would make the package be infozip-6.1-x86_64-1_slack14.2.txz (notice how the version number on python stayed the same and changed with infozip).

Yes, that is what I mean exactly. If I understood correctly one of the concerns Pat had with rebuilding the entire software tree in current a little while ago was the fear of exposing regressions. I know a few things would not even build anymore at least. I don't recall personally seeing any gcc regressions expose issues in the main tree before, but I have seen it a few times in programs available at SBo. Sometimes its simply exposing a hidden preexisting bug in the program which just happened to work before while other times the bug is in the compiler. This is similarly true for any other dependency a program may link against or otherwise use, for example boost is a c++ library that often causes issues in other programs when updated because the upstream boost developers don't prioritize backwards compatibility, but another program may have developers that care much more about compatibility and upgrades will less likely cause problems.

Basically in the context of the Slackware changelog a rebuilt package is when Pat bumps the build number and runs the SlackBuild script again to create a new package that is built against the current Slackware tree which may have new patches, changes to the configuration files and it will use the current versions of dependencies on the system which may cause different behavior if they have changed themselves. An upgraded package is when the upstream developers release a new version of their program which could have few or many changes. This is highly variable, some programs release new versions for every commit while others don't release new versions for years at a time if ever.

@bassmadrigal, @orbea - Thank you very much for your in-depth and thorough explanations :) The differences are much clearer now.


A couple of examples would be Suckless Tools. I use their terminal. They provide a patch that allows you to use .Xresources to configure the terminal, otherwise you have to modify the config.h directly and then recompile. If I were to apply the patch and recompile it would be considered a rebuild. If ST applied the patch themselves and bumped the version number it would be considered an upgrade.

Another one would be from an article that was posted here about a Debian maintainer stepping down. He mentioned how he wanted the maintainer of rsync to apply a patch but they refused. If debian went ahead and patched rsync themselves it would be a rebuild, if the maintainer accepted the patch and bumped the version number it would be an upgrade.

In both cases the final result of the program is exactly the same, the only difference is who applied the patch and if the version number changed.

Can I nag you about one more thing? Here by "current" are you referring to "-current" or just the present state of stable and -current?

I'm not very familiar with debian, but not exactly. If a package maintainer applies a patch its always a rebuild, an upgrade is only when the package's version is changed which is usually done by the upstream developers, but sometimes the distros will do it themselves especially if upstream has died or in the case of distro specific packages (i.e. pkgtools in Slackware). A maintainer applying patches could be modifications to make it work, backported patches from upstream to resolve issues in the stable package release, personal taste and occasionally I have seen maintainers apply patches out of sheer incompetence...

Yes I mean Slackware current as opposed to Slackware stable.

Thanks for your reply, orbea :)

Sorry, I conflated the two terms.

Here is the excerpt I was referring to:

By maintainer they most likely mean someone at Debian who maintains the rsync package. I mistakenly thought he was referring to the actual developer of rsync (upstream).

What I meant to say is if the developer of rsync applied this patch and bumped the version number then it would be considered an upgrade, but if the Debian maintainer of rsync applied the patch it would be a rebuild. Of course, I mean this generally. I do understand what you said about how distros will sometimes do it themselves.