Packaging pyroscope

Michael Schwendt mschwendt at gmail.com
Fri May 25 09:34:36 UTC 2012


On Fri, 25 May 2012 13:41:14 +0530, Ankur Sinha wrote:

> What worries me is that pyroscope has a "rtorrent-extended" interface,
> which is just application of some patches to the original rtorrent
> source. It even uses the rtorrent tars, the code isn't forked or
> anything.

What exactly you plan to package (and how and with which name) is not
known yet, isn't it? I'm not familiar with the status for "pyrocore" and
other parts of pyroscope.

Pyroscope is not just the patched rtorrent UI. It's a collection of stuff,
e.g. additional scripts.

Btw, earlier you wrote:

 | It adds quite a lot of functionality to rtorrent. 

Does it matter whether it modifies the source code via patches or in
its own tree? In its present form it's a fork.

> Therefore, we will end up maintaining two copies of rtorrent
> in a way (the original and the extended (original + patches)). Should
> this be done?

Such questions are difficult to answer. Ask yourself: Does rtorrentExtended
(or whatever you plan to package, e.g. extra scripts/tools) offer enough
extra stuff to be packaged as an alternative? Are you interested enough
in rtorrent to comaintain it, since you would depend on it anyway? Is the
project active enough to update their patches whenever an important or
security relevant rtorrent release becomes available? Do you think this
thing is maintainable with its dependency on the rtorrent source?

> I'm not sure why these patches haven't been added to rtorrent upstream
> yet. I'm looking into it.

Good idea. That may answer the question whether rtorrentExtended is
supposed to be a fork or whether it is just a set of proposed experimental
patches that will be applied upstream eventually.

-- 
Fedora release 17 (Beefy Miracle) - Linux 3.3.7-1.fc17.x86_64
loadavg: 0.43 0.19 0.24


More information about the devel mailing list