[SHR-unstable]

Klaus 'mrmoku' Kurzmann mok at mnet-online.de
Sun Jul 5 11:56:52 CEST 2009


Am Sonntag 05 Juli 2009 00:39:27 schrieb Robin Paulson:
> 2009/7/5 Klaus 'mrmoku' Kurzmann <mok at mnet-online.de>:
> >> > Running
> >> > $ find /usr -name "libelementary.so*"
> >> > gives nothing.
> >>
> >> it'll be there, but called something else. the shr team change the
> >> name every so often, by adding a string of letters to the name of all
> >> the e libraries. it's probably something like:
> >
> > no, NOT so. It is NOT the SHR team and you know that. It is enlightenment
> > upstream that changes libnames with every freeze they do right now. That
> > will change when they release something stable.
> >
> > And yes, we could work around that. Though we do not have the proper
> > manpower to do that :(
>
> well, that's only half the story, isn't it?
>
> shr team chooses which packages to include, so yes they are
> responsible for what they produce.
yep, we're responsible for deciding to bump the revision of E we use.

>
> as raster's pointed out, these releases aren't for public consumption
> but for testing only. you could very easily stick to the blessed
> releases, and not break every shr install out there on every update.
quoting raster:
"Eina, Evas, Ecore, Embryo, Edje, E_Dbus, Efreet and Enlightenment have had a
snapshot release (snapshot 061), Elementary 0.5.0, and can be downloaded from
http://download.enlightenment.org/snapshots/2009-06-14 . If
you are taking source from SVN - http://svn.enlightenment.org, then
use SVN revision 41040."

We're taking E source from SVN - so we did what he recommended and upgraded E 
to 41040.

>
> or, if you need help doing something, and don't have the manpower -
> ask. i'm sure there are many willing volunteers who would work on
> fixing this. it's really frigging annoying.
believe me - it frigging annoys me too. Just the way you phrased your mail it 
sounded like it is SHR deliberately deciding to rename libraries. Which is not 
true. 

The real problem might just be that SHR has no stable release yet. Because in 
the end we're talking about SHR *unstable*. And we have to bump the 
enlightenment version we use from time to time to get fixes and enhancments, 
don't you agree?

So, this time we took care to rebuild all packages that needed rebuilding. 
This fixes the packages which are in our feed only though. Problems come from 
packages you install from other sources.

What could we do about that? Yes, we could add some compatability lib package 
that adds symlinks from for example libevas-ver-svn-02.so.0 to libevas.so.0.
Raster would hate us for that btw. because this could theoretically lead to 
bogus bugreports from programs linked against an older lib but running with 
the newer one. The ABI in enlightenment world is *not stable* yet. Don't know 
how probable that would be though...

I would propose two things:

a) bug us to get all those packages you want into the SHR feed. This gives us 
the possibility to cleanly rebuild them whenever needed (and spank us if we 
fail to do so :)

b) find a volunteer to do a script adding those links or even a package. We 
certainly could ping that volunteer *before* doing such an upgrade - to give 
him/her time to do that script

What do you think?
-- 
Klaus 'mrmoku' Kurzmann



More information about the community mailing list