With the lpf package under way to fedora stable and the first lpf-* packages on their way into rpmfusion there is an issue with the review process fo llpf-* packages (an lpf package). An lpf package is basically a wrapper for the spec for a target package. E. g. lpf-skype contains lpf.skype.spec and skype.spec.in (see [1]). Formally, when reviewing the lpf-skype package a reviewer should review the package spec i. e., lpf-skype.spec. However, this is just some copy-paste code which is more or less the same for all lpf packages. It's still evolving, but it should be more or less a non-issue when reviewing.

On Sex, 2013-11-22 at 13:32 +0100, Alec Leamas wrote: > With the lpf package under way to fedora stable and the first lpf-* > packages on their way into rpmfusion there is an issue with the review > process fo llpf-* packages (an lpf package). > > An lpf package is basically a wrapper for the spec for a target > package. E. g. lpf-skype contains lpf.skype.spec and skype.spec.in (see > [1]). > > Formally, when reviewing the lpf-skype package a reviewer should review > the package spec i. e., lpf-skype.spec. However, this is just some > copy-paste code which is more or less the same for all lpf packages. > It's still evolving, but it should be more or less a non-issue when > reviewing. > > However, each lpf package contains a target spec, skype.spec.in in the > example. This is the real stuff, the package user installs after > building it. IMHO, the target spec should be the real issue when > reviewing. In a short perspective, I'm trying to keep this lpf thing in > a limited number of hands, so this is not a concern right now. > > However, I think it's time to formalize this for rpmfusion. Since lpf > packages are rpmfusion only, we cannot lean on the Fedora review > guidelines for this. Even the tooling (fedora-review) is totally blind > for the target package. Which boils down to a simple question: should we > have a rpmfusion rule that when reviewing lpf packages the target spec > and package should be reviewed somehow (as well as the "normal" spec, > normally a non-issue)? Or should we just close our eyes, since we dont > distribute the target packages? Hi, Brilliant idea !. Second though: I don't believe that lpf is made in bash, I know that you can do all with bash but so many lines!, it could be done in so many languages, I prefer Python , but with Perl you could do much more easy scripting .

Yes , we need do some rules :), for example seems to me that License of lpf-something.spec should be the license of something.spec.in , and others fields too.