Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=477870 Mat Booth <fedora@xxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(fedora@xxxxxxxxxx | |o.uk) | --- Comment #15 from Mat Booth <fedora@xxxxxxxxxxxxxx> 2009-02-03 16:12:31 EDT --- Hi Andrew, thanks for taking the time. (In reply to comment #13) > I'll take this review. > > Everything looks good to me. I have a few questions: > > - does this comment mean we have reduced functionality? > > "... these files aren't needed for source plugins; they are only needed > "so the example-installer plugins can create full projects in your > workspace)" > No, nothing is lost. I will change that comment to be clearer. The files are still included such that they are present when you create the sample plugin projects in your workspace. (They are merely omitted from the associated source plugins of the sample plugins in the same way they are omitted from the associated source plugins of all other regular plugins.) If that makes any sense. To see what I mean just try creating some of the EMF sample plugins projects through the new example wizard and making sure the .project/.classpath files get created. > - could we match upstream's qualifier instead of that of the build? I worry > this will give multilib conflicts since the builds on x86_64 and x86 will > happen on different machines without the same hour and minute. If we can't > match upstream's qualifier (in the case they're all different), just set it to > something sane so all arches end up the same. I'm not sure I understand the multilib concern; this is a noarch package. It's no bother to change the qualifier though. Does it have any significance above being just the time it was built? > - why not use separate dropins directories for the sub-packages? This gives a > much cleaner %files section > No real reason beyond keeping the directory structure the build process gave me. (The resulting zip expands neatly into a single dropin directory during %install.) I can change it if you'd prefer. (In reply to comment #14) > As for the > > FIX rpmlint shows no warnings > > The only one is this: > > eclipse-emf.noarch: W: obsolete-not-provided eclipse-emf-standalone > > I think we need a Provide there as well (see > http://fedoraproject.org/wiki/PackagingDrafts/ProvidesObsoletes) > Erm, yeah. It was after reading that link that I decided that we *don't* need a Provides there because we no longer provide the files that the obsoleted package provided in a compatible way. From that article: "if a package supersedes/replaces an existing package without being a compatible enough replacement as defined in above, use only the Obsoletes". That way of using EMF is genuinely obsolete and no longer supported upstream (and I don't believe there are any packages in Fedora that depend on it anyway). Is it really necessary to Provides it? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review