Red Hat Bugzilla – Bug 508194
RFE: split /usr/bin/padre into own subpackage
Last modified: 2010-03-01 05:31:40 EST
Created attachment 349494 [details]
spec file patch
It would be nice (and make more sense) if we could split /usr/bin/padre into a "padre" subpackage here, the same way we do for nopaste (perl-App-Nopaste), asciio (perl-App-Asciio) and git-cpan-patch (perl-Git-CPAN-Patch), to name a couple.
I've attached a patch to do this :)
I'd like to add it into rawhide in version 0.36, which is waiting for threads update. Thank you for your patch.
Awesome :) This should make it easy to add to the "Perl Development" group in comps.xml, too :)
I have strange feeling that there wasn't any agreement on packages which should be in devel group in comps.
I'm not in favour to add f.e. all Catalyst modules and omit some other modules which could be used by bigger group of "silent" users. Maybe the devel group could be filled with modules which has the biggest score on cpan or number of downloads, in case it has to be created.
Take a look at what's in comps.xml.in right now; the packages listed in there now fall under "a package should be in this group if it's reasonably related to Perl development and it's not just one of the zillion perl-* packages." Padre would seem to me to be a package like that.
We can discuss this more on the list as needed. :)
IMHO: padre is just one application amongst many. Having it in comps.xml is greasy kid-stuff and doesn't make any sense at all.
I'll split this in next update. I'm planning update after perl-5.10.1 where are threads in version which is needed by padre package.
Finally it was updated, but now I don't see any gain from splitting it into two sub-packages. Could you explain it more?
Having the application (/usr/bin/padre) in a "padre" package would distinguish it from perl libraries (e.g. perl-*), make it consistent with git-cpan-patch, asciio, no paste and others, and make it easier for end-users to find and install.
Well, it's not a rule, so not every package is split on library and application subpackages. End-user can install Padre even if we provide it, which looks more clean to me.
I solve this by providing padre binary in Provides. Now it's possible to install by 'yum install padre'.