> 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.
Call them things like %l
On Wed, May 21, 2008 at 9:11 PM, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> Gerard Beekmans wrote:
>>> 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
On Wed, May 21, 2008 at 9:00 PM, Alexander E. Patrakov
<[EMAIL PROTECTED]> wrote:
> Gerard Beekmans wrote:
>> So to summarize simply using the %configure macro won't run it like we'd
>> want the configure script to be run.
Yeah. %configure would do a lot more than ./configure. Not that that's
a ba
> 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 %configure for RPM). Now Bruce wonde
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
>> instructions), this is not how
Alexander E. Patrakov wrote:
> Gerard Beekmans wrote:
>
>>> Yes. Note that I have not evaluated pacman.
>>>
>> Do you by chance have any plans or desire to do so in the near future?
>>
>
> Not in the nearest future--too busy with bureaucracy that surrounds
> presenting
> the disser
> 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 are supposed to
> 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* PM in
> LFS?
As an option
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 possible to write dummy files
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 information for
Gerard Beekmans wrote:
>> 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 overr
Gerard Beekmans wrote:
> 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?
Why not just say somewhere on the PM page tha
> 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 one thing to keep in mind
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
Gerard Beekmans wrote:
>> Yes. Note that I have not evaluated pacman.
>
> Do you by chance have any plans or desire to do so in the near future?
Not in the nearest future--too busy with bureaucracy that surrounds presenting
the dissertation (scheduled for July, 3).
>> What's even more important
> 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? Couldn't RPM spec fil
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 made it sound (to me
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 (config
19 matches
Mail list logo
