[Fedora-packaging] Re: --vendor fedora, rationale/motivation?

[Axel Thimm]

Hi,

this discussion resulted in some recommendations in the guidelines and
elsewhere, but old packages are supposed to keep any naming (vendor)
they used for backwards compatibility with menu editors, correct?

I just removed the fedora- prefix from the smart package and Ville
(correctly) raised the guidelines violation flag. While I just did the
change w/o reading/understanding the compatibility note, afterwards I
came up with similar reasoning as to why all packages should get fixed
as Rex below. My main arguments in favour of properly fixing it are:

o EPEL support: I don't want to fork a package specfiles just for
  supporting a legacy buglet, nor do I want to overcomplicate it with
  checing for fedora vs rhel.

o buglet propagation: Most if not all packagers reuse their work. When
  I need a desktop/info install or something similar I cut and paste
  from one of my older packages, or perhaps from another good
  package. If such legacy buglets are kept then they get copied all
  along. Of course commenting would help.

All in all the pain with doing such a change is that some customized
user menues may suddenly lose en entry, which the user can easily dnd
back. Therefore I don't think it is worth while to keep the pain in
the specfiles, instead upon updating of such a specfile it should be
cleaned up desktop-file-wise.

What do you think?

On Fri, Mar 03, 2006 at 09:47:47AM -0600, Rex Dieter wrote:
>  Per
>  http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines:
>  The vendor prefix (desktop-file-install --vendor=...) must be set to
>  fedora".
>  
>  I don't understand the rationale/motivation behind requiring '--vendor
>  fedora'
>  
>  I can, however, see that desktop-file-install's current
>  implementation(*) of prepending %{vendor}- to the .desktop file name has
>  some problems/issues:
>  1.  .desktop filename now varies from upstream
>  2.  --vendor may change when/if Extras bits are pulled into Core and/or
>  RHEL.
>  3.  *In particular*: when users start employing menu editors, since
>  most(all?) of them base their customizations on the .desktop file name.
>  
>  -- Rex
>  
>  (*) If desktop-file-install's implementation instead followed something
>  like kde's practice of using a vendor directory (e.g.
>  /usr/share/applications/kde), then (1) and (3) would no longer be an issue.
>   
-- 
Axel.Thimm at ATrpms.net