#666 Issue closed: What RPM package version extension for adapted rear packages?¶
Labels: documentation, fixed / solved / done
jsmeix opened issue at 2015-10-08 08:33:¶
@gdha, @schlomo
When a Linux distribution adapts a rear version to match special needs of that specific distribution, what does rear upstream recommend as RPM package version extension that the Linux distribution should use for its adapted rear packages?
Assume the Linux distribution's package is based on rear 1.17.2 (i.e. it is rear 1.17.2 with some patches from the Linux distribution).
Then the Linux distribution's RPM package versions could be something like
rear-1.17.2.1 rear-1.17.2.2 rear-1.17.2.3 ... rear-1.17.2.a rear-1.17.2.b rear-1.17.2.c ...
or something else?
Reasoning and background information:
Currently I am working on https://github.com/rear/rear/issues/556 ("Implement support for recovery when what is mounted at '/' is a btrfs snapshot subvolume"). Right now I have some kind of "proof of concept" patched into rear 1.17.2 to make it work specifically for the default btrfs structure in SLE12-SP1. Because my current implementation is basically a SLE12-SP1 specific hack, I do not yet want to submit that to rear upstream. First I will provide my hack only to SLE12-SP1 users both to SLE12-SP1 customers via a SUSE package and also publicly to SLE12-SP1 users via an openSUSE package from OBS (project "Archiving" package "rear"). Afterwards as a second step (ideally after sufficient SLE12-SP1 users feedback) I will try to implement it in a generic way that is inteded to work on all Linux distributions. The latter one will be of course submitted to rear upstream (via GitHub pull request).
jsmeix commented at 2015-10-08 08:44:¶
Interestingly the issue number of this numbering issue is "the number of the beast" - hopefully this is not a bad omen...
jsmeix commented at 2015-10-08 09:41:¶
For now I use
rear-1.17.2.a rear-1.17.2.b rear-1.17.2.c ...
because a letter extension makes the difference more obvious than just one more number.
Furthermore I assume that rear upstream will not use letters but instead e.g. rear-1.17.2.1 for a sub-release of rear 1.17.2.
In such a case I could use rear-1.17.2.1.a for a SUSE-specific patched package that is based on rear-1.17.2.1.
Finally the current extension 'a' would even correctly indicate that my current patch is in "alpha" state and a subsequent extension 'b' matches perfectly "beta" - only for 'c' I do not yet know a good meaning.
gdha commented at 2015-10-08 13:42:¶
@jsmeix We have no intention to go further then major.minor.subnr schedule. So, indeed a letter would make a distinction between upstream and vendor sub-release.
jsmeix commented at 2015-10-08 14:19:¶
@gdha many thanks for your prompt reply!
I had meant that a letter makes a distinction between upstream and vendor sub-release even if rear upstream decided at some time to go further then major.minor.subnr.
Right now I made my current SLE12-SP1 specific implementation public available in the openSUSE Build Service development project "Archiving" package "rear".
If you like to have a look what I changed and what needs to be set in /etc/rear/local.conf for recovery of SLES12-SP1 with default btrfs structure, see SLE12-SP1-btrfs.patch and SLE12-SP1-btrfs-example.conf at
https://build.opensuse.org/package/show/Archiving/rear
[Export of Github issue for rear/rear.]