[Gnu-arch-users] applications of an Arch user's ~/.arch-params/=id

[Sean Champ]

Hello,

To introduce myself and this message: I'm hoping to develop an Arch client
that would be operable in Common Lisp. Granted, I don't have much to show
for the design of it, presently. I intend that it will be defined as part
to an SCCM support library  to the Tioga project -
http://common-lisp.net/project/tioga/  of which I am the administrator and,
presently, the sole developer. (As such, there's not much to show there,
right now).

In regards to the Arch support in the SCCM library, I have gotten so far,
about it, as to have produced a mechanism for creating Common Lisp objects
that would be representative of Arch archive designators and revision
designators. (This should be easier to demonstrate, at at ime when the code
for it will be publicly available. What I have for it, it might undergo
some refactoring, before being finally published.)


I'm trying to determine how a user may be respresented, within the system.

I am not aware of whether or not I know all of the means in which the value
in a user's ~/.arch-params/=id file is applied, in all operations on an
Arch archive. 

In how a user's ~/.arch-params/=id  value is used by Arch, will it be used
in anything additional to the defaulted production of a file's archive
identifier?


(I'm aware that I may be able to determine an answer to my question, simply
in looking at the Arch sources. However, I am not certain if I will be able
to determinedall of the existing applications of the value, if I would only
grep across the sources. I am aware that I am not as familiar with the code
as would be an Arch developer.)


I take it that it would be in the production of a file's archive-id, one
means by which a user's =id identity would be applied. 

If there may be any more by which the value would be used, in operations
onto an Arch archive, I would be grateful if anyone might have an
opportunity to mention it. I hope to be sure that I will have covered all
the bases, about it.



Thank you

--
Sean Champ