replaceable-handling (was: question to postfix instructions (long))

Reinhard bookreader at gmx.com
Wed Mar 24 23:44:57 PST 2004


On Wednesday 24 March 2004 21:31, Larry Lawrence wrote:
> "Reinhard" <bookreader at gmx.com> wrote in message
> > I supposed that the  <replaceable> ... </replaceable> is used to trigger
> > the editor from nALFS, so I wanted to keep that untouched for the
> > profile-migration.
>
> As far as I know <replaceable></replaceable> shouldn't be used by alfs in
> any shape or form.  

Did you really mean "should not"? 
This pattern is consitently used over LFS and BLFS - if I remember well - and 
there where plans in the alfs-team for an internal editor (I'm not involved, 
I only read about it).

> It is used by an editor (person writing) to identify
> strings that must be changed prior to executing the command.
> In most renderings, the string is in italic to get it noticed.  
> It works nicely because users that cut-n-paste from rendered copies 
> never pick up the <replaceable></replaceable> because it was stripped 
> during rendering (in this case xml source -> DSSSL stylesheets -> html).

Yes, of cause. I know, that the <replaceable>-pattern is not rendered to the 
(end-)user, so I considered it "internal information" too.
I don't think it is appropiate, put the values of all <replaceable>'s into 
nALFSrc or something similar. I agree with you, that the values change for 
any user (any build?), so they have to be replaced just before the build.

I consider the alfs-profiles "internal information" too. I don't see any 
reason, having the (end-)user edit a profile, so for me the profile has the 
same status than the book (with the difference, that the profile is an 
excerpt from the book).

Therefor I thought, it is appropiate, transfer the <replaceable>-patterns to 
the profiles. For me, the <replaceable>-pattern is the same as 
entity-references, which also are content of the profiles and for so needs 
the entities to be extracted from the book.

> > Same problem I found in configuration-section of mplayer.
> > There's a link command with ...<replaceable>[font size]</replaceable>...
> > AFAIK unquoted filenames in X-World may not contain spaces.
> > So how about to change [font size] to [font-size].
> >
> > With that little change, the rules for filename are met and the
> > <replaceable>...</replaceable> could be transferred to nALFS-profiles.
>
> Again, my primary concern is to the reader, so my preference is how it is,
> but the change your proposing is not one that I would contest. 

> I am having trouble following the 'filename' examples here.  In this case,
> '<replaceable>[font size]</replaceable>'  needs to be converted to '18',
> for example. This is user chosen within valid parameters, so at some point
> this has to be defined by the user during the automation process and then
> substituted into the instructions by alfs for execution.  There are several
> ways to do this and I can't standardize the source for all of them.

See this discussion in context of your mentioned utopia.
I understood it that way. So let me follow your example.
The ...<replaceable>[font size]</replaceable> [cs]ould be different for any 
user.
This has to be true for an alfs-profile also. 
So alfs needs an trigger to replace such a value. I don't care, whether this 
is also called <replaceable>, it's a nice name and phony, so why not.

I guess, that [font size] does not have a cross-reference within the book, 
it's only a literal displayed with different style as eyecatcher.
So I think, there's no harm to change the [font size] to [font-size].
It stil might serve as an eyecatcher and the profile-converter will not break.

> I can't standardize the source for all of them.

From my point of view, this is not your interest and not your job.
Is it ok for me, to bring such details to discussion and/or ask for changes?
So it's yours to decide on those.

>  As the "proof of concepts" unfold, I should be able to determine the
> 'most likely' winner and then I can verify that the source is compatible.

Sorry, but I think I don't understand this sentence. The winner should always 
be the user of LFS-products (book, tools, what ever) - or ... ?

> > One question about dependencies.
> > I have the glimpse, the (some) editors don't like to have the
> > dependencies meet the installation instructions.
> > How about to add the (unwanted) dependencies in an entity-section, so the
> > information is there (in the book), but does not get rendered to the
> > HTML-variant.
> > Could that be a compromise?
>
> Are we talking about dependencies outside the BLFS universe?

Not only. The references from the book which point to the 'nowhere' outside 
BLFS, are perfectly OK.

Staying on your example OpenSSL - I remember, there was an dependency to 
Kerberos. The dependency-walker stated that as 
	"Kerberos is not part of the book."

For me, it's good enough. You know, there's a dependency to outside and you 
have to do that on your own.

If I remember well, I had some troubles building heimdal, so I understand why 
that package is not part of the book.
  
> If I put a dependency in the book, I have to believe it is usable by my
> 'average user', so testing is an issue here.  

Well, I don't think, I meet the 'average user'.

Right after finishing lfs, I wanted to install ssh[d], wget, nfs(client) and 
mc - so that I could work on my distro-box connected to the lfs-box.
Then I thought, start with a little step and for so start building the 
server (without x).

Some packages failed to build, cause the dependencies where not mentioned or 
the status of the dependencies was mentioned 'Optional', where the configure 
failed without that package.
That was quite anoying.

The other point was, after 10 (or more) times writing "./configure --prefix=/
usr && make && make install", I missed one time the --prefix.
S..t - how to recover?
I didn't know, so I started again after chapter 5 with a clean device.

May be, I was to dump to meet your 'average user'.
But I'm quite sure, no one would install all packages of blfs.
Further I believe, the book is a tool to mature with.
But it won't be, if you only get frustrated with your first steps.

> Make some suggestions, I feel like I can justify all the dependencies in the
> book as they are based on feedback and usage, but I have no problem walking
> through them here for review.

I don't ask for others doing that work. I'm willing to check the dependencies 
and provide the diffs. It's just a discussion point - also with context to 
utopia, without any timeline.

I would like to have the dependencies meet the install-instructions from the 
book. This leads to the following meaning of qualifier:

Required
 - when the build-process (with the build-instructions from the book) fails in 
absence of that package.

Optional
 - when the build gets enriched by the presence of that package (no matter, 
whether configure gets rid of the presence of the package, or whether it 
needs an additional switch)

Recommended
 - (YES, I like this qualifier) is like "Optional", but reflects a 
recommendation of the [B]LFS-team. Like the usage of vim in the LFS (I like 
vim, but I know, many others don't) it's a recommendation. From the mailing 
lists, I suppose, that gnome could be also a recommendation, ...
Using dependency-trackers, the user could choose, whether to prefer a minimal 
installation (Recommended is treaten Optional), or whether he likes to do a 
recommended installation (Recommended is treaten Required).

Well, my dream of a dependency-tracker is, if for example you just finished 
with lfs and step to blfs seeing that bunch of packages and you don't have an 
idea of what you need, so if you decide, you like to install 'OpenOffice' and 
start a dependency-tracker, that will tell you, what packages you have to 
install first = means: what chapters you have to look at.

For me, blfs is a big universe, unmanageable without tools or experience.
So the first thing to need is a path through the chapters (but please only 
those chapters, I like/need to install) - so a dependency-tracker is needed.
Such a tool is only that good, as the dependencies in the book.

Therefor I'm so annoying on that item.
I appreciate [BA]LFS a lot and I like your utopia. 

I believe, that an dependency-tracker makes to book more attractive and will 
decrease the number of support-mails.

Cheers Reinhard




More information about the blfs-dev mailing list