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 17:37:25 -0300

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.

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.

In this area in particular, there is no benefit whatsoever.

And if we kept things separate and generic, perhaps someone else
would find it useful too.

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

Also, testing of different steps of the build, with changes in the
middle, could be easier.




Archive powered by MHonArc 2.6.24.

Top of Page