Le 03/03/2014 22:30, Fernando de Oliveira a écrit :
> Em 03-03-2014 17:43, Bruce Dubbs escreveu:
>> Fernando de Oliveira wrote:
>>> Em 02-03-2014 21:42, Ken Moffat escreveu:
>>>> On Sun, Mar 02, 2014 at 05:16:44PM -0600, Bruce Dubbs wrote:
>>>>> We just released LFS-7.5 and we need to look at releasing BLFS-7.5 in
>>>>> the next few days. AFAIK, all the 7.5 tickets are complete and all the
>>>>> packages tagged for 7.5. It is just a matter of doing the release, but
>>>>> I'm sure that there are some tweaks that are necessary.
>>>>>
>>>>> For planning purposes, I think we can target Wednesday. March 5.
>>>>>
>>>>> Comments?
>>>>>
>>>> The --libexecdir switches still look a bit iffy to me.
>>>>
>>>> 1. The following use --libexecdir with what I think are adequate
>>>> explanations of why: vte2, acl, dhcpcd. Anyone who disagrees :
>>>> please speak up!
>>>>
>>>> 2. The following explain an optional --libexecdir switch: gnupg2,
>>>> emacs, librep, geoclue. I don't have a problem with leaving this
>>>> sort of thing in for a transitional period while people may still be
>>>> using older versions of LFS (does 3 years sound about right?), BUT
>>>>
>>>> (i.) the markup is '<parameter>', I think it hould be '<option>' ?
>>
>> From a logical standpoint I think both fit. They are options to the
>> ./configure command, but are also parameters in that they are a "set
>> that defines a system or sets the conditions of its operation".
>>
>> However I do think our use should be consistent. In the html, option is
>> inside of <code> constructs. We define that in the css to be monospace.
>> For the parameter, we the text is inside <em><code> tags that render
>> as monospace slanted on my system. We do not define em outside of a
>> note, warning, etc.
>>
>> Which we choose probably doesn't make much difference. I would select
>> option just because it is less keystrokes.
>>
>> In any case, I don't think it's enough of an issue to hold up release of
>> BLFS-7.5.
>>
>>>> (ii.) should we also do this for all other existing BLFS packages
>>>> which now use /usr/libexec ?
>>>>
>>>> 3. Subversion used to run a subshell to interrogate apxs. The
>>>> current page looks unusual, but I haven't any desire to build it for
>>>> 7.5 (I only rebuilt my server in September), so I have to assume it
>>>> is ok ?
>>>
>>> More or less. I am comparing the two versions in BLFS svn and 7.4 (It is
>>> very good to having releases, so to easily comparing instructions
>>> versions. In "Command Explanations", of svn (7.5-rc1) I think we should
>>> write the complete switch, or it is almost useless:
>>>
>>> s|=...|=$(/usr/bin/apxs -q libexecdir)|
>
> I took from the wrong one.
>
>>>
>>> In configure, I don't know how to handle the switch alone
>>> "--with-apache-libexecdir"
>>
>> I'm confused. Where is that sed?
>
> Not sed. I mixed up a bit and it got confusing. ĸen: "Subversion used to
> run a subshell to interrogate apxs".
>
> {{{
> BLFS-7.4:
> ./configure --prefix=/usr \
> --disable-static \
> --with-apache-libexecdir=$(/usr/bin/apxs -q libexecdir) &&
>
> Command Explanations
> ...
> --with-apache-libexecdir=...: This switch sets Apache HTTPD module
> install dir.
> }}}
>
> {{{
> BLFS svn:
> ./configure --prefix=/usr \
> --disable-static \
> --with-apache-libexecdir &&
>
> Command Explanations
> ...
> --with-apache-libexecdir: If Apache-2.4.7 is installed, the shared
> Apache modules are built. This switch allows to have those modules
> installed to Apache's configured module dir instead of /usr/libexec. It
> has no effect if Apache is not installed.
> }}}
>
> If I am understanding correctly, ĸen is talking about that difference,
> and that it would be good to have somewhere
>
> --with-apache-libexecdir=$(/usr/bin/apxs -q libexecdir)
>
> I do not deal with apache nor apxs, so I am not sure how to modify, as
> we have a parameter and an option very similar.
>
> But I think ĸen may be right.
>
with the switch: --with-apache-libexecdir (without =), what configure does is
the following (IIRC):
- if apache is not found: nothing
- if apache is found: run "apxs -q libexecdir". This command returns a
directory name (the directory used by apache to put modules). Configure then
sets Makefile so that (i) apache modules are built and (ii) those modules are
installed to the found directory.
If this switch is NOT passed at all, what configure does is:
- if apache is not found: nothing
- if apache is found, build apache modules and put them in /usr/libexec
The full switch --with-apache-libexecdir=$(/usr/bin/apxs -q libexecdir) is not
very good, because it runs apxs unconditionally, even if apache is not
installed. Since apxs is part of apache, it throws a warning (IIRC again) when
apache is not there. Since the behavior is the same without the =$(...)
part, I do not see a reason for having it. Now removing the switch completely
is not wrong either.
For the command explanations, I rely on Bruce's English, rather on mine...
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
