Bug 508194

Summary: RFE: split /usr/bin/padre into own subpackage
Product: [Fedora] Fedora Reporter: Chris Weyl <cweyl>
Component: perl-PadreAssignee: Marcela Mašláňová <mmaslano>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: mmaslano, perl-devel, rc040203
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-01 10:31:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
spec file patch none

Description Chris Weyl 2009-06-26 01:42:19 UTC
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 14:23:45 UTC
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 19:00:18 UTC
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 07:25:45 UTC
I have strange feeling that there wasn't any agreement on packages which should be in devel group in comps. 

http://www.mail-archive.com/fedora-perl-devel-list@redhat.com/msg09402.html

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 15:32:47 UTC
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 15:38:42 UTC
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 11:01:55 UTC
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 11:10:30 UTC
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 18:57:46 UTC
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 13:40:50 UTC
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 10:31:40 UTC
I solve this by providing padre binary in Provides. Now it's possible to install by 'yum install padre'.