checksum verification in nALFS

Mark Ellis mark.uzumati at
Mon Oct 14 09:51:03 PDT 2002

On 2002.10.13 19:29 Vassili Dzuba wrote:

I'm only half following all this, gotta spend time job hunting (guh!)
so bear with me.

> Even without the <reference>, I think that we should still perform by
> default
> the validation of the checksum in (or very near to) the <unpack>.
> Let's assume that a get a new BLFS profile and that i want to update
> only one or two packages. I can load it into nALFS, choose
> interactively
> the package i want to build, and type 's', 'c'.
> But if the validation of the checksum is performed at the beginning
> of the profile, it will not be done here.
> Of course, we can consider that the checksum is a declarative element,
> put it at the beginning at the document.
> The syntax could then be :
>     <alfs version="3.0">
>         <digest type="md5">
>              <path>&packages_dir;/&bash_package;</path>
>              <value>&bash_md5</value>
>         </digest>
>         ....
>             <unpack>
>                  <archive>&packages_dir;/&bash_package;</path>
>                  <destination>&build_dir</destination>
>             </unpack>
>      ...
>      </alfs>

Some of this is i think getting overly complex because the operation
of the backend is being tied too closely to the syntax. Essentially we
have an archive (tarball, whatever), and a key (checksum, signature),
and a way of specifying these in the syntax. An attribute or element in
<unpack><archive> would be fine.

The backend can then do whatever it wants with this information. For
instance, on executing the profile it reads in the tree and collects all
the archive and key information and checks everything out to start with.
You could even use XSLT to strip out the necessary info before you parse
the whole profile.

A specific instruction to check archive integrity should _not_ be a part
of the syntax, only the information to enable it to do so.

> Of course the price is a more complicated behaviour of nALFS where an
> action
> associated with an element must search the tree, but i think it is
> probably
> acceptable.


Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list