Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] [RFC] Compressed filetype detection (Bug #16011)

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Ismael Luceno <ismael.luceno AT gmail.com>
  • To: Jaka Kranjc <smgl AT lynxlynx.info>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] [RFC] Compressed filetype detection (Bug #16011)
  • Date: Sun, 15 May 2016 19:31:55 -0300

On 15/May/2016 23:37, Jaka Kranjc wrote:
> On Sunday 15 of May 2016 17:37:25 Ismael Luceno wrote:
> > On 15/May/2016 21:31, Jaka Kranjc wrote:
> > > On Sunday 15 of May 2016 16:04:39 Ismael Luceno wrote:
> > > > I am thinking about having the uncompression, checksumming, signature
> > > > verification, etc. all reworked and split into a separate unit, so
> > > > that we can make it more flexible and streamline all tasks related
> > > > to the inspection, packing and unpacking of spell sources, which I
> > > > hope makes it easier to build better tools, specially to automate
> > > > spell creation and inspection, and which could remove the need to
> > > > specify information like BUILD_DIRECTORY into the spells.
> > >
> > > They're already in separate "units" — libraries. How could they be any
> > > easier to reuse? If you're missing some more high-level interfaces, that
> > > is trivial to add.
> >
> > It is only simpler to reuse within sorcery. Doing complex changes,
> > experiments, with sorcery is nowadays not simple.
> Eh? Nowadays? What did you try to do and what stopped you? Maybe as a
> counter-
> example, when I wrote the update mode for quill, sorcery hardly changed to
> make that possible.
>
> If you for some (odd) reason don't want to load all sorcery, you can still
> only load what you need. Quill does that for faster startup and then loads
> the
> rest.

For example: I've been interested in adding a new configuration
mechanism for spells, and that does require far more changes than it
should; switching back and forth between both isn't an option, but it
could be if sorcery were designed in a more loosely-coupled fashion,
if we could simply make configuration an add-on.

> > The problem I see with sorcery is that it is too tightly coupled,
> > it's exactly the opposite of what unix is meant to be, and for no
> > good reason.
> Examples, proof? I'm sure some functions could be split further and libmisc
> cleaned up, but that's bordering on nitpicking. Code is reused when a need
> is
> shown. Most of it is in thematic library functions, there's plenty of
> modularity and layering, so it's pretty bizzare that you accuse it of tight
> coupling. Especially since it is written in bash where it is trivial to
> redefine functions at runtime.

Implementing new functionality is a pain: proper binary support,
reproducible builds, changing the flow of the build mechanism, any
behaviour and about any change big or small requires to modify sorcery
itself in incompatible ways, and thus forces us to add more and more
code paths and compatibility workarounds that would be unnecessary if
we could just replace components at run-time. An example of this is
the new switch for comparing spell versions, if sorcery were designed
differently, it would have required no changes, just a new utility,
completely independent from the rest of sorcery.

Having a more unixy implementation, we could simply redefine parts
of sorcery, switch back and forth, and compare results effortlessly
in the more intrusive cases, while new functionality that is not
vital could be provided by separate packages that could be provided
by spells, and none of this would alter the core installation, nor
it's functioning, everything becomes explicit.

Competing features and implementations of functionalities could be
installed and work side-by-side unhindered.

We can work towards that.

> > > The only reason I can think of for a separate BUILD_DIRECTORY var is
> > > that
> > > some archives don't extract to expected locations. In case they create
> > > more than one top-level directory, the correct one can't be
> > > deterministically guessed, so I doubt the var can go away. I guess it's
> > > also partly a verification mechanism.
> >
> > For the few spells that are not tarbombs or similar, we can add an
> > extra line in BUILD, the rest can be automatically fixed.
> >
> > This could also be a step forward to allow easier incompatible parallel
> > builds, sharing the rest of the system, which could in turn be unified
> > with the cross-building support for a more uniform approach.
> Parallel builds of the same spell sounds like a bad idea. Perhaps ok for
> the
> individual level, but imagine it being part of a queue. And an
> automatically
> different build dir wouldn't solve much, since you still need a different
> install and potentially track root. There's no way to guess that, so what's
> an
> extra var to specify when invoking cast?

It is just one of the prerequisites to implement support for binary
spells, along with isolation, repeatable builds, and some verification
infrastructure among other things.

> > Also, testing of different steps of the build, with changes in the
> > middle, could be easier.
> What do you miss in delve? AFAIK it was created for exactly this reason.

I meant changes in sorcery, not in the spell. Those changes could be
made external to sorcery if it weren't a single entity.




Archive powered by MHonArc 2.6.24.

Top of Page