rpms/gnokii/devel gnokii.spec,1.24,1.25

[Ville Skyttä]

On Friday 21 March 2008, Bastien Nocera wrote:
> On Fri, 2008-03-21 at 19:28 +0200, Ville Skyttä wrote:
> > On Friday 21 March 2008, Bastien Nocera wrote:
> > > Except that the vendor shouldn't have been used in the first place,
> >
> > Why?  It's recommended by the freedesktop.org desktop menu spec, and more
> > than recommended by the Fedora packaging guidelines.  What's the problem
> > that needed fixing?
>
> It doesn't match upstream. When I install from source, I end up with 2
> icons in the menus and it pisses me off.

With all due respect, I think that's pretty far fetched.

If you install from source to /usr/local, you're effectively masking the 
packaged one in /usr - why not just remove the packaged one?

If to /usr, you're overwriting files of the package and the next package 
update will blow away your changes again - why not remove the packaged one?

Both of the above will practically end up making rpmdb dependencies no longer 
reliable anyway so it should no longer be any concern if you need to remove 
the packaged one with --force.

If you install from source to somewhere else for your private use, why not 
while at it use the same vendor prefix for the .desktop as is in the Fedora 
package, knowing that Fedora packagers are a responsible bunch and don't go 
renaming the .desktop file because they know what kind of problems doing so 
will cause to users?

In this case, upstream doesn't yet follow the freedesktop.org recommendation 
of using a vendor prefix, but that could change because they too know that 
it's the packagers' (or source builder's) job to ensure that the installed 
filename will stay the same in all their builds and thus users of those 
builds will not face breakage even if upstream takes a vendor prefix in use.  
So I claim it's more likely that upstream installed .desktop filename changes 
than the one in well maintained packages.

> > Between releases or not, I think Fedora has enough problems not breaking
> > things between updates without maintainers intentionally inflicting more
> > of them.
>
> That's a minor inconvenience more than anything else...

Minor inconveniences add up quickly.  And individual ones become easily larger 
when users find out that there was in fact no good reason (I don't think your 
example above counts as one) why the inconvenience existed in the first 
place.  We don't need that.