LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 03-19-2019, 08:13 PM   #1
Mechanikx
Member
 
Registered: Jul 2018
Location: Canada
Distribution: Slackware
Posts: 120

Rep: Reputation: 78
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:

Quote:
Sun Mar 3 22:03:39 UTC 2019
patches/packages/python-2.7.16-x86_64-1_slack14.2.txz: Upgraded.
Updated to the latest 2.7.x release, which fixes a few security issues.
...
(* Security fix *)

Fri Mar 1 20:46:01 UTC 2019
patches/packages/infozip-6.0-x86_64-4_slack14.2.txz: Rebuilt.
Added some patches that should fix extracting archives with non-latin
characters in the filenames. Thanks to saahriktu.
This update also fixes various security issues in zip and unzip.
...
(* Security fix *)
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
 
Old 03-19-2019, 08:22 PM   #2
montagdude
Senior Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 1,456

Rep: Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086Reputation: 1086
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.

Last edited by montagdude; 03-19-2019 at 08:37 PM.
 
2 members found this post helpful.
Old 03-19-2019, 09:46 PM   #3
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,545

Rep: Reputation: Disabled
Quote:
Originally Posted by montagdude View Post
there's no inherent reason why rebuilding a package would cause instability.
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.
 
1 members found this post helpful.
Old 03-19-2019, 10:19 PM   #4
willysr
Senior Member
 
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 3,963

Rep: Reputation: 1224Reputation: 1224Reputation: 1224Reputation: 1224Reputation: 1224Reputation: 1224Reputation: 1224Reputation: 1224Reputation: 1224
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.
 
2 members found this post helpful.
Old 03-20-2019, 12:13 AM   #5
Mechanikx
Member
 
Registered: Jul 2018
Location: Canada
Distribution: Slackware
Posts: 120

Original Poster
Rep: Reputation: 78
Thank you for your explanations, montagdude!

Quote:
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.
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?


Quote:
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.
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.
 
Old 03-20-2019, 12:23 AM   #6
Mechanikx
Member
 
Registered: Jul 2018
Location: Canada
Distribution: Slackware
Posts: 120

Original Poster
Rep: Reputation: 78
Quote:
Originally Posted by orbea View Post
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.
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"?
 
Old 03-20-2019, 12:25 AM   #7
Mechanikx
Member
 
Registered: Jul 2018
Location: Canada
Distribution: Slackware
Posts: 120

Original Poster
Rep: Reputation: 78
Quote:
Originally Posted by willysr View Post
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 willysr, this helped a lot!
 
Old 03-20-2019, 01:11 AM   #8
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 5,874

Rep: Reputation: 3585Reputation: 3585Reputation: 3585Reputation: 3585Reputation: 3585Reputation: 3585Reputation: 3585Reputation: 3585Reputation: 3585Reputation: 3585Reputation: 3585
Quote:
Originally Posted by Mechanikx View Post
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?
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:

Code:
Sun Mar 3 22:03:39 UTC 2019
patches/packages/python-2.7.16-x86_64-1_slack14.2.txz: Upgraded.
Updated to the latest 2.7.x release, which fixes a few security issues.
...
(* Security fix *)

Fri Mar 1 20:46:01 UTC 2019
patches/packages/infozip-6.0-x86_64-4_slack14.2.txz: Rebuilt.
Added some patches that should fix extracting archives with non-latin
characters in the filenames. Thanks to saahriktu.
This update also fixes various security issues in zip and unzip.
...
(* Security fix *)
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).
 
3 members found this post helpful.
Old 03-20-2019, 09:11 AM   #9
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,545

Rep: Reputation: Disabled
Quote:
Originally Posted by Mechanikx View Post
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"?
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.
 
2 members found this post helpful.
Old 03-20-2019, 02:16 PM   #10
Mechanikx
Member
 
Registered: Jul 2018
Location: Canada
Distribution: Slackware
Posts: 120

Original Poster
Rep: Reputation: 78
@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.

Quote:
Originally Posted by orbea View Post
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...
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?
 
Old 03-21-2019, 09:23 AM   #11
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,545

Rep: Reputation: Disabled
Quote:
Originally Posted by Mechanikx View Post
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.
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...

Quote:
Originally Posted by Mechanikx View Post
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?
Yes I mean Slackware current as opposed to Slackware stable.
 
1 members found this post helpful.
Old 03-21-2019, 02:24 PM   #12
Mechanikx
Member
 
Registered: Jul 2018
Location: Canada
Distribution: Slackware
Posts: 120

Original Poster
Rep: Reputation: 78
Thanks for your reply, orbea

Quote:
Originally Posted by orbea View Post
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...
Sorry, I conflated the two terms.

Here is the excerpt I was referring to:

Quote:
Lastly, changes can easily be slowed down significantly by holdouts who refuse to collaborate. My canonical example for this is rsync, whose maintainer refused my patches to make the package use debhelper purely out of personal preference.
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Upgraded distro which upgraded perl and modules from old version not transferred to new. systemlordanubis Linux - Software 1 03-25-2018 03:37 AM
LXer: Fedora 24 Linux to Ship with GCC 6 by Default, Most Packages Need to be Rebuilt LXer Syndicated Linux News 0 12-25-2015 02:27 PM
LXer: Board Meeting, Rawhide Rebuilt, Firewall Debate, ARM 64, and DNF as Yum Replacement (5tFTW 201 LXer Syndicated Linux News 0 06-12-2014 09:10 AM
I deleted my panel and am having trouble getting it rebuilt leupi Linux - Newbie 4 01-29-2010 01:25 PM
LXer: How do I prevent rebuilt packages from being upgraded? LXer Syndicated Linux News 0 02-13-2006 12:46 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 09:34 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration