You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 9, 2019. It is now read-only.
When one does a yaourt -Su, it lists the packages to update in the following fashion:
==> Package upgrade only (new release):
(list of packages with a new revision)
==> Software upgrade (new version) :
(list of packages with a new version)
Meaning, if a package start at version 3.7.1-2, if the new version is 3.7.1-3 (the -3 changed) it goes to the first list while if the new version is 3.7.2-1 (the .2-1 changed) it goes to the second list. This is not all that helpful, since a lot of packages update from A.B.C to A.B.(C+1) without changing much. It'd be more useful to let the user decide how to split the list of updates.
The simplest way would be to define a split behavior config: in a A.B.C-D scheme, one would be able to configure where is the limit between a version change and a small release.
A nicer approach (from the user's point of view) would be to be able to define a default behavior and lists of packages that fall in each possible behavior. For example, some programs follow the old linux versioning style (A is major version, B is release, C is small release), while others follow the firefox/chrome/new linux style (A is release).
The lists would need to be created, but that effort can be crowdsourced once the functionality is there :-D (or someone with historical info on package versions can do a decent first estimation with a script)
The text was updated successfully, but these errors were encountered:
yaourt is just following the Arch package naming standards which are described here and here.
More specifically, the number after the - represents PKGBUILD version while the version string before the - represents the software version and matches the upstream versioning.
The separation is clear in the sense that if you see a package in the Software upgrade (new version) section, you know that it's been updated by the upstream. How much it has changed in fact, that you cannot tell without looking into that software's changelog or release notes.
To your proposal, it seems to me like a huge work but providing doubtful benefits.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When one does a
yaourt -Su
, it lists the packages to update in the following fashion:Meaning, if a package start at version
3.7.1-2
, if the new version is3.7.1-3
(the -3 changed) it goes to the first list while if the new version is3.7.2-1
(the .2-1 changed) it goes to the second list. This is not all that helpful, since a lot of packages update from A.B.C to A.B.(C+1) without changing much. It'd be more useful to let the user decide how to split the list of updates.The simplest way would be to define a split behavior config: in a
A.B.C-D
scheme, one would be able to configure where is the limit between a version change and a small release.A nicer approach (from the user's point of view) would be to be able to define a default behavior and lists of packages that fall in each possible behavior. For example, some programs follow the old linux versioning style (A is major version, B is release, C is small release), while others follow the firefox/chrome/new linux style (A is release).
The lists would need to be created, but that effort can be crowdsourced once the functionality is there :-D (or someone with historical info on package versions can do a decent first estimation with a script)
The text was updated successfully, but these errors were encountered: