> Right, that's why I was saying you'd probably want to minimize the
> macro usage in general. However, from the perspective of someone using
> RPM, I really want to use the macros.
Make up our own? We then need to distribute that as part of the rpm
package installation.
Ca
s a
>>
>> So to summarize simply using the %configure macro won't run it like we'd
>> want the configure script to be run.
>>
>> Can't it be overridden or introduce our own %configure-like macro that
>> does run things like the book does?
>
>
ook does?
You can override all the macros or not use them at all.
> Why not just say somewhere on the PM page that we don't use the %configure and
> similar macros in our spec files (and call ./configure directly instead)
> because
> we want 100% correspondence between commands i
> As far as I understand, the outcome was (roughly) that LFS needs to provide
> at
> least a no-PM and PM versions, with a well-known PM. And a requirement has
> been
> formulated that the commands must match between these two versions (thus
> ruling
> out %configur
Gerard Beekmans wrote:
>> Both RPM and Debian package managers require writing a set of control files
>> in
>> order to create a package. Although it is possible to write dummy files
>> containing only packaging information for pre-built files (and no building
>>
ucracy that surrounds
> presenting
> the dissertation (scheduled for July, 3).
>
>
>>> What's even more important for educational purposes, Debian rules are
>>> incoherent
>>> between various Debian packages.
>>>
>> How does RPM diff
> Both RPM and Debian package managers require writing a set of control files
> in
> order to create a package. Although it is possible to write dummy files
> containing only packaging information for pre-built files (and no building
> instructions), this is not how these tools
> I guess I don't understand. Are we going to create a source RPM for every
> package and then install from that? I didn't think that was our intention.
No, the LFS book will remain the LFS book.
> This seems to be the knotty problem. Just how are we going to *use* P
Alexander E. Patrakov wrote:
> Bruce Dubbs wrote:
>> This seems to be the knotty problem. Just how are we going to *use* PM in
>> LFS?
>
> Both RPM and Debian package managers require writing a set of control files
> in
> order to create a package. Although it is po
Bruce Dubbs wrote:
> This seems to be the knotty problem. Just how are we going to *use* PM in
> LFS?
Both RPM and Debian package managers require writing a set of control files in
order to create a package. Although it is possible to write dummy files
containing only packaging infor
want the configure script to be run.
>
> Can't it be overridden or introduce our own %configure-like macro that
> does run things like the book does?
I guess I don't understand. Are we going to create a source RPM for every
package and then install from that? I didn't thi
t say somewhere on the PM page that we don't use the %configure and
similar macros in our spec files (and call ./configure directly instead)
because
we want 100% correspondence between commands in no-PM and RPM versions of LFS?
--
Alexander E. Patrakov
--
http://linuxfromscratch.org
> for any bog standard autotooled package:
>
> %configure
>
> Looks simple enough: it runs ./configure for you. However, there's a
So to summarize simply using the %configure macro won't run it like we'd
want the configure script to be run.
Can't it be overridden or introduce our own %configur
On Sun, May 18, 2008 at 6:54 PM, Gerard Beekmans
<[EMAIL PROTECTED]> wrote:
>
> Dan, you have done a lot of work with RPM spec files for LFS. Is there
> anything you wish to add to what Alexander said back then and your own
> reply to it?
Alexander may have said this, but on
on Monday, May 19, 2008 at 9:46 Alexander E. Patrakov wrote:
" What's even more important for educational purposes, Debian rules are
incoherent
" between various Debian packages.
As one of those being educated by all of this (in more ways than you can
possibly imagine, a genuine and heartfel
; What's even more important for educational purposes, Debian rules are
>> incoherent
>> between various Debian packages.
>
> How does RPM differ in that regard? Couldn't RPM spec files (in theory?)
> suffer from the same problem depending on who writes them?
RPM doesn&
> Yes. Note that I have not evaluated pacman.
Do you by chance have any plans or desire to do so in the near future?
> What's even more important for educational purposes, Debian rules are
> incoherent
> between various Debian packages.
How does RPM differ in that regard?
Gerard Beekmans wrote:
> This continues the emails Alexander sent a while back (March 5).
>
> Alexander, am I correct in my assumption that you would consider RPM a
> good choice and DEB a bad choice for LFS purposes.
Yes. Note that I have not evaluated pacman.
> Your emails ma
This continues the emails Alexander sent a while back (March 5).
Alexander, am I correct in my assumption that you would consider RPM a
good choice and DEB a bad choice for LFS purposes.
Your emails made it sound (to me) that deb would be a lot harder to
implement, maintain and understand
Bruce Dubbs wrote:
> I would like to add RPM to BLFS because it is required for a system to be
> compliant with the Linux Standards Base.
Which version? 4.x and 5.x are completely different beasts. Anyway, LFS
contains
a severe deviation from LSB (no libncurses.so.5 by default, only
On Sun, Mar 2, 2008 at 7:07 AM, Alexander E. Patrakov
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have digged up the archives of LeafOS lists and extracted RPM instructions
> and
> spec files from them. Spec files up to and including Chapter 6 bash are
> attached
> (s
Hello,
I have digged up the archives of LeafOS lists and extracted RPM instructions and
spec files from them. Spec files up to and including Chapter 6 bash are attached
(slightly modified).
Dan: sorry for ignoring your superior work.
Differences from the book: the toolchain adjustment
22 matches
Mail list logo
