Public SourceMage Discussion List

[Thomas Orgis <thomas-forum AT orgis.org>]

I'm all for getting some action going.

Am Thu, 4 Sep 2014 21:30:37 +0200
schrieb Remko van der Vossen <wich AT yuugen.jp>: 

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

I'm trying to start that over the weekend.

> - Devel branch owners should create a good UP_TRIGGERS for spells with
>   ABI incompatible changes compared to test and prepare for pushing to
>   test after stable-rc has been prepared

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.

I guess getting a living graphics stack including gtk and cairo, with
some window manager and xterm is a reasonable goal, already tricky
enough. I won't venture into desktop environments.

> Who is with me?

The whole team --- I'd rather wonder about the abyss they're pushing
you into;-)

> Why are our dependency trees so inaccurate?
> 1) we choose to omit dependencies that are covered by basesystem
> 2) we don't check our DEPENDS files for correctness, as long as it
>    compiles we assume it's correct

Didn't we have some scripting already to find missing depends? I
remember some thoughts from lynx back when attending SMEG (anyone
else?).

> Switching to as-needed already takes care of a very, very large part of
> the dependency tree problem.

What is your view on the number of spells that have issues with
as-needed?

> 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`?

> Lastly we come to the cyclic dependencies.

Detecting them and suggesting to the mage to intervene manually could
already help. But indeed, it shouldn't block us from going forward,
since cyclic deps have been there forever (cast x11 and gs together,
say yes to optional deps on each other).


> 1) We have to get as-needed everywhere. Without as-needed we have no
> hope in hell of getting any reasonable casting orders and thus always
> end up in upgrade hell. So, to everyone I say, get latest devel
> sorcery on your box

So, before upgrading to new test grimoire, users should rebuild with
as-needed or face consequences. How do we communicate that (assuming
there are users that are not reading this list, one can dream)? Or,
well, I guess it makes sense to do the rebuild with the fresh stable
(aka test now) for a slightly higher chance to find source tarballs
(I'm trying to fill up my mirror and promise not to delete things
before it runs out of space).

>, (maybe we should make a new stable sorcery,)

+1

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

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.

I hope to get away without linux-pam, as I loathe it's foolishly easy
ways of seriously configuring it badly.


Alrighty then,

Thomas

Attachment: signature.asc
Description: PGP signature