[Bug 477870] Review Request: eclipse-emf - Eclipse Modeling Framework (EMF) Eclipse plugin

[bugzilla at redhat.com]

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 at matbooth.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Flag|needinfo?(fedora at matbooth.c |
                   |o.uk)                       |




--- Comment #15 from Mat Booth <fedora at matbooth.co.uk>  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.