On Wed, 2016-08-31 at 18:08 -0400, Dave Reisner wrote: > On Wed, Aug 31, 2016 at 11:18:32PM +0200, Gordian Edenhofer wrote: > > > > > > > > > > > > > > > > > > > The second probably would not be accepted... > > > > > > > > I urge you to reconsider. Parallelization increases the speed > > > > of > > > > this > > > > > > I don't think anyone is suggesting that packaging multiple things > > > in > > > parallel isn't useful. I already suggested that nothing needs to > > > be > > > implemented in bacman proper in order for you to parallelize the > > > work. > > > You can write your own "pbacman" as simply as: > > > > > > for arg; do bacman "$arg" & done; wait > > > > There is a huge difference between flooding your system with ~1000 > > jobs > > and tightly controlling the maximum number. Adjusting the precise > > number of jobs enables you to organize your resources which itself > > is > > desirable. > > Then use a program like 'parallel' which has this sort of knob. I > really > wonder what it is you're doing that requires running bacman with a > large > number of packages with any regularity.
Sure, parallel is an awesome program. However I already explained why I chose to write this patch and added more functionality to bacman: Save time for other users. The added code is modest in size and enables anyone to significantly speed up their bacman process by having a look at the man page and without downloading an additional ~5000 line perl program. Please also consider that this patch is about more than just parallelization: It adds a manual page, some useful command line options and let bacman handle abort signals. > > Even if there would be a perfect wrapper for bacman - which there > > is > > none - it would still make sense to implement easily understandable > > options into bacman for everyone to use simply to spare others the > > time > > of coming up with one.
signature.asc
Description: This is a digitally signed message part
