Summary: | sys-apps/coreutils cp --progress is gone without any notice | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Petteri Räty (RETIRED) <betelgeuse> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | aksansai, antoni, dma147, floyd_n_milan, gentoo, hiyuh.root, jens.kager, martin, mlohse, telefrancisco |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
001_coreutils-gen-progress-bar.patch
coreutils progressbar patch for coreutils 8.4 |
Description
Petteri Räty (RETIRED)
![]() that's because it's a custom Gentoo patch that upstream rejected (In reply to comment #1) > that's because it's a custom Gentoo patch that upstream rejected > Doesn't mean you couldn't add an ewarn about it. Isn't there about a million gentoo-patches in most important core-system packages, that the upstream would never think of including for many reasons? What a damn stupid explanation. We want this back, reopen the bug, please. [a] (In reply to comment #3) > Isn't there about a million gentoo-patches in most important core-system > packages, that the upstream would never think of including for many reasons? > Actually it is the Gentoo policy to try and keep as close to upstream as possible. I would try to get this feature included upstream instead so that everyone would benefit. no, there arent actually generally we push things upstream or we punt them *** Bug 154651 has been marked as a duplicate of this bug. *** So which patch is it? And who do we contact about it? I wouldn't mind submitting the patch over to the upstream guys myself if i knew. read the patch for upstream information Wouldn't it be possible to make a USE flag to enable this patch? Why not just leave the choice to the users? I like this patch. I'd want to use it, even if it isn't used upstream. `rsync --progress file1 file2` works better than `cp -g file2 file2` *** Bug 157520 has been marked as a duplicate of this bug. *** (In reply to comment #10) > `rsync --progress file1 file2` works better than `cp -g file2 file2` This is plainly wrong if you e.g. copy to a dvdram where the only reasonable policy is to limit the number of read/write operations and where a progress bar is really useful. You can do a little better with rsync --inplace, but this is still worse than cp. Things become even worse if you want to copy several large files (in which case rsync reads the destination directory data "in vain"): rsync was simply never meant as a substitute to cp for such a purpose. Moreover, there are other things which cp can which rsync cannot do at all (e.g. -i and probably also some other options). Actually, I considered it always as one of the main advantages of gentoo that it was easy for the user to have patches like this - simply because they are convenient - instead of forcing the user to follow some group's philosophical considerations as in other distros. I am very sad to see that gentoo gives up such an advantage for absolutely no reason. May I ask what reason upstream gave for rejecting the patch? if you read the patch i documented it all in the header A Solution for this "problem" which is a very good example for the typical mentality of the gentoo-devs can be found here: $ emerge -av layman $ layman -S $ layman -a dma147 $ emerge -av coreutils I've re-inserted this patch since version 6.7-r1... so you maybe have to go testing: $ echo "sys-apps/coreutils" >> /etc/portage/package.keywords . (In reply to comment #14) > if you read the patch i documented it all in the header Where is this patch you keep referring to. I want to read it. You keep telling people to read it but don't say where the hell it is. here's a crazy idea ... it's in the Gentoo coreutils patchset Created attachment 182615 [details, diff]
001_coreutils-gen-progress-bar.patch
Old Gentoo progress bar patch no longer works with newer versions of coreutils.
Here's an updated one.
Note if you're used to the old one using option '-g', this one uses the option '-B' to achieve same.
And yes, I'm aware that it will never be included in the coreutils ebuild, this is just for the benefit of the many users who still use it or want to use it in their own overlays.
i'd add that to the patchset except it isnt a complete port Created attachment 226591 [details, diff]
coreutils progressbar patch for coreutils 8.4
the (complete) attached diff builds against coreutils-8.4
Any chances for new patch? Last version this one is working is 8.5(-r1). [removing myself from CC] ive added it to the 8.{1,2,3,4,5} patchsets, but it's still not going to be enabled by default, nor is it updated to 8.6+ |