Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Biting Bullets

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Ismael Luceno <ismael.luceno AT gmail.com>
  • To: Sukneet Basuta <sukneet AT gmail.com>
  • Cc: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] Biting Bullets
  • Date: Sat, 13 Sep 2014 13:51:16 -0300

On Sat, Sep 6, 2014 at 1:53 PM, Sukneet Basuta <sukneet AT gmail.com> wrote:
<...>
> 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.
>

+1.

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

+1, definitely, that would be far more reliable, and IIRC Debian does
that since eons ago.

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

+1.


Also, I am for removing some choices, like as-needed, it should be
forced, not just enabled by default, I do not see any reason to not
use it, and it's not like toolchains don't force new behaviors down
our throat all the time anyway.

And probably make some part of the system static in order to avoid
breakage, I have seen bash and gawk break a couple of times, and I've
been working on compiling stuff statically against musl for a while
with remarkable results. Also we could probably make mawk a dependency
to sorcery, sorcery seems to work fine with it after a little patch,
and it's faster and slimmer.




Archive powered by MHonArc 2.6.24.

Top of Page