[blfs-dev] Upcoming BLFS-7.5 release

Fernando de Oliveira famobr at yahoo.com.br
Mon Mar 3 13:30:21 PST 2014


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.

> 
> I do note that in the subversion explanations section is the wording:
> 
>    "This switch allows to have those modules installed ..."
> 
> which probably should be changed to
> 
>    "This switch installs those modules ..."
> 

OK.

> 
>>>
>>> 4. The following are still doing things the old way:
>>> menu-cache, qemu, openbox, mc, pulseaudio.  Is there any reason why
>>> these should NOT drop --libexecdir ?
> 
>> menu-cache and openbox are my faults. I can fix them.

I will do menu-cache and openbox early tomorrow.


-- 
[]s,
Fernando



More information about the blfs-dev mailing list