Overview
Request 484838 accepted
- Use update-alternatives according to current documentation
- Disable tar-1.26-remove_O_NONBLOCK.patch - this issue has been
fixed in tar-1.27
- backup-scripts subpackage change to noarch
- Change rpm group of tar-tests to Development/Tools/Other
- Enable rmt building, change package description
- Switch rmt to alternatives system
- Separate rmt subpackage - it can be used by different archiving
tools as a dedicated program
- Change rmt path to /usr/bin folder - it can be used by non privileged
users for backup purposes. Security is controlled by access rights to
the targets and remote shell.
- Separate doc subpackage
- Remove conditions for old SUSE builds and lang subpackage
- Rename restore script to restore.sh for avoiding file conflicts
with dump/restore
- Created by svalx
- In state accepted
- 4 package maintainers
- Supersedes 482971
Request History
svalx created request
- Use update-alternatives according to current documentation
- Disable tar-1.26-remove_O_NONBLOCK.patch - this issue has been
fixed in tar-1.27
- backup-scripts subpackage change to noarch
- Change rpm group of tar-tests to Development/Tools/Other
- Enable rmt building, change package description
- Switch rmt to alternatives system
- Separate rmt subpackage - it can be used by different archiving
tools as a dedicated program
- Change rmt path to /usr/bin folder - it can be used by non privileged
users for backup purposes. Security is controlled by access rights to
the targets and remote shell.
- Separate doc subpackage
- Remove conditions for old SUSE builds and lang subpackage
- Rename restore script to restore.sh for avoiding file conflicts
with dump/restore
kstreitova accepted request
Thanks!
@kstreitova, @mseben, @msmeissn, @vitezslav_cizek: review reminder
@svalx: Just a small note, if the O_NONBLOCK issue is fixed in tar 1.27, I guess we can remove this patch (not just disable it). Or do you see any reason not to do this?
I am guided by the https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Patch_life_cycle, left it so far just in case.
Hm, it could make sense in cases where you are not sure about removing but in this case, I think that it's pretty clear that it was fixed in upstream (btw. good catch!). So I will remove this patch.