[SHR-unstable]

[Robin Paulson]

2009/7/5 Klaus 'mrmoku' Kurzmann <mok at mnet-online.de>:
>> 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.

right, good. we can work with that

>> 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.

i don't know then - the last discussion i was involved in on this, i
interpreted what he said differently. that might be my fault though

>> 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.

yeah, i was partly being flippant. guess it doesn't carry on email

> 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

yes, that's true. i can totally accept an unstable release which has
unknown bugs - that's part of using unstable. but a team repeatedly
releasing packages with the *same* bug and saying "we know it's
broken, we're not going to fix it, it's a good decision" (to
paraphrase mwester iirc), but not explaining why is something else
entirely, particularly when several make the same complaint

also of course, many are using unstable because in a lot of ways, it's
so much better than testing. i switched because it was *more* stable
than testing. if testing could be relied upon, i'm sure plenty would
dwitch, and you wouldn't get people like me complaining about this

> enlightenment version we use from time to time to get fixes and enhancments,
> don't you agree?

yes, but if i can't use the software written against enlightenment,
it's not much use getting those enhancements, is it? we can't file bug
reports if the ABI is changing more rapidly than the software written
to use it. i've got to the point now where i can't be bothered getting
any of the e stuff to work. it seems to break so often, with no
discernible improvement.

> 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

yes, i understand that now. it's what everyone does anyway though

> 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...\

well, stable is what you make of it. if you want to bless svnrev 40894
or whatever, then do that. then, rather than releasing a new blessed
svn every two weeks with different names, skip some. is it more
important to shr team to get shr stable via bug reports, or to get e
stable via bug reports? you're not obliged to follow what e team
wants. an yes, raster would hate that idea.

> 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 :)

right, everything made by c_c: intone, tasks, launcher

> 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

b) is me. tell me what you want, and i'm glad to help. better than
trying to get endless users fixing it each upgrade by individually
creating symlinks

i realise now that what you're doing is not entirely insane - until
now no-one's explained it and the reasons behind it anywhere near as
well as you have.

cheers

rob