Re: [evolution-patches] Version independent desktop/keys file

[Mark Gordon <mtgordon ximian com>]

On Tue, 2005-09-13 at 11:03 -0400, Rodney Dawes wrote:
> On Tue, 2005-09-13 at 18:02 +0530, Harish Krishnaswamy wrote:
> > On Mon, 2005-09-12 at 12:00 -0400, Rodney Dawes wrote:
> > > Is there any particular reason to not go ahead and remove the parallel
> > > installability bits for everything else too? Doing it for just the
> > > desktop and mime types stuff (which we should probably dump at some
> > > point anyway, since the keys/mime files aren't used any longer, that
> > > I know of), pretty much means that we are going to break it. 
> 
> > What gets broken specifically ?
> 
> Parallel installability within the same prefix.
> 
> > > This means
> > > that if a user installs unstable evolution, the menuitem for the stable
> > > version, will get replaced for the menuitem for the unstable version,
> > > and the user won't be able to launch the stable version from the menus
> > > any longer. And, they probably aren't going to be able to use it
> > > reliably anyway.
> 
> > No. I guess not. Only the stable version would have been installed with
> > the enable-default-binary option set. Any developer who wishes to have a
> > parallel unstable installation would not be enabling the option.
> > (So the symlink still points only to the stable version). 
> > He w(sh)ould create a fresh launcher linking directly to the binary he
> > has built (which obviously is in a different install location and has
> > the version suffixed to its name). 
> 
> No. If you don't have any evolution installed, and you don't do
> --enable-default-binary, then what happens? You just installed
> evolution, and it doesn't show up in the menus? That seems wrong. The
> fact that the desktop files and things will conflict with those that
> already are installed means that evolution is no longer parallel
> installable. We can't have it be a requirement that people create their
> own desktop files in the menu structure for development installs. That
> is ridiculous, and not usable at all. Anyway, the only real way to have
> a parallel installation after this change, would be to install in a
> different prefix. I don't see why we should make it more difficult to
> have things Just Work, by avoiding changing the other aspects related to
> having evolution be parallel installable, so that it definitely isn't.
> 
> > > It would be nice to do all or none, and not be stuck somewhere in the
> > > middle.
> > > 
> > What changes do you think are missing - that *must* be done to do it
> > 'all' ?
> 
> Getting rid of --enable-default-binary so that it always just installs
> as "evolution", remove version information from files where it isn't
> really needed, such as the bonobo server files and such. All of that
> really.
> 
> -- dobey

The primary use case for parallel install is the parallel install of
stable and development versions, right?

These can be distinguished at build-time from the version number, right?

How about some logic to create names derived from (but not strictly
including) the version number?  Even version -> "evolution", odd version
-> "evolution-unstable".  Then you could install, in parallel, exactly
one stable version and exactly one development version, which is pretty
much all anyone needs.

People sticking to stable versions wouldn't have any more migration
issues, and people moving to new bleeding-edge sweetness would be spared
a little work as well.

-Mark Gordon