Public SourceMage Discussion List

[Sukneet Basuta <sukneet AT gmail.com>]

On Thu, Sep 4, 2014 at 3:30 PM, Remko van der Vossen <wich AT yuugen.jp> wrote:

SUMMARY

What I feel should be done;

- Everyone should move to as-needed aggressively; switch on as-needed
  and sorcery rebuild your systems

If we are going to rely on this, it should be pushed as the default in Sorcery with a warning if one wants to disable it.

 

3) We need to get the devel-* branches up to scratch so that we can get
them merged into master after a new stable-rc has been created. Whether
we all merge them at once and go for a big bang or whether we do them
one by one between successive stable-rc cycles we should still discuss.
What does it mean to get them up to scratch? The ABI incompatible
changes need to be identified and good UP_TRIGGERS scripts need to be
created as described above. Then upgrading from master to the devel
branch has to be tested on a few as-needed-i-fied systems and major
manual steps necessary to upgrade should be recorded.

I'd like to request that everyone who opens a devel branch create a bug stating why it was created, what is needed to get it merged into test, and the specific spells of interest. This will help keep everyone in the loop and allow other people to contribute. As it stands, I only really know what is going on in the devel-xorg branch because I've played around with it quite a bit. As an example: http://www.sourcemage.org/issues/423

On Fri, Sep 5, 2014 at 4:32 PM, Thomas Orgis <thomas-forum AT orgis.org> wrote:

We once had a testing approach that started with basessytem to ensure
one doesn't get irrevocably fritzed, then we wanted to expand this ...
what is the base install we start with for testing the upgrade from
current test to the devel stuff? Shall we include Xorg and some
graphics libs? Excluding those would nicely get around the
pthread-stubs issue, but I suppose you're not aiming for that easy way
out.

IMO Xorg is necessary these days.

 

> So, what do we do about this problem? Again, we cheat! We find all
> dependers, not by our dependency tree, but by checking all installed
> spells for dynamic ELF objects

I sense that this should be either done once for the whole system
(using cleanse) and cached, further automatically on each cast after
INSTALL, right? That way, using `gaze from` style look-up, we can even
auto-suggest additions to DEPENDS. Actually ... how does that relate
to `cleanse --delint`?

+1
We could do this before every spell is installed and store all the link dependencies in a file. Then maybe add them as a depends whenever it is recast? It may help with better dependency resolution. 

 

> I'll take care of devel-libpng, who will take ownership of the other
> two?

Ah, back we are: I wondered who these "owners" are. I do have some
interest in the xorg branch, as it's the only thing that works for me. I
have a hard time with the decisions there, though. Is mesalib-1x
supposed to be renamed to mesalib again? The old spell (and thus, the
MESALIB provider) is useless now. Also, we should settle treatment of
llvm upgrades (see sm-commit), as it's a sensitive requirement for
current mesalib.

I personally detest all these spell-1x spells. When I type "cast packageName", I expect the latest stable upstream version. If I didn't look into sorcery every now and again, I wouldn't be aware of spells like mesalib-1x.

 

Am I right in assuming that the "only" troubles are libpthread-stubs
and the newer drivers? I am in the "lucky" position to use the three
main video drivers (intel, radeon, nouveau). I'm not sure about libxcb,
I didn't seem to have trouble with it.

Based on my experience, yes. Those are the only problems I've run into.