Bug 508194 - RFE: split /usr/bin/padre into own subpackage
RFE: split /usr/bin/padre into own subpackage
Product: Fedora
Classification: Fedora
Component: perl-Padre (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-06-25 21:42 EDT by Chris Weyl
Modified: 2010-03-01 05:31 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-01 05:31:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
spec file patch (1.89 KB, patch)
2009-06-25 21:42 EDT, Chris Weyl
no flags Details | Diff

  None (edit)
Description Chris Weyl 2009-06-25 21:42:19 EDT
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 :)
Comment 1 Marcela Mašláňová 2009-06-26 10:23:45 EDT
I'd like to add it into rawhide in version 0.36, which is waiting for threads update. Thank you for your patch.
Comment 2 Chris Weyl 2009-06-26 15:00:18 EDT
Awesome :)  This should make it easy to add to the "Perl Development" group in comps.xml, too :)
Comment 3 Marcela Mašláňová 2009-06-29 03:25:45 EDT
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.
Comment 4 Chris Weyl 2009-06-29 11:32:47 EDT
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. :)
Comment 5 Ralf Corsepius 2009-06-29 11:38:42 EDT
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.
Comment 6 Marcela Mašláňová 2009-08-21 07:01:55 EDT
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.
Comment 7 Marcela Mašláňová 2010-01-18 06:10:30 EST
Finally it was updated, but now I don't see any gain from splitting it into two sub-packages. Could you explain it more?
Comment 8 Chris Weyl 2010-01-18 13:57:46 EST
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.
Comment 9 Marcela Mašláňová 2010-01-19 08:40:50 EST
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.
Comment 10 Marcela Mašláňová 2010-03-01 05:31:40 EST
I solve this by providing padre binary in Provides. Now it's possible to install by 'yum install padre'.

Note You need to log in before you can comment on or make changes to this bug.