Re: [CVS] RPM: rpm/build/ parsePrep.c
On Fri, Jul 20, 2007, Jeff Johnson wrote: [...] simplify macro undefined test, remove absolute path restriction. Ah, even better. Thanks, Jeff. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/build/ parsePrep.c
On Jul 20, 2007, at 9:02 AM, Jeff Johnson wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org Name: Jeff Johnson
Root: /v/rpm/cvs Email: [EMAIL PROTECTED]
Module: rpm Date: 20-Jul-2007
15:02:47
Branch: HEAD Handle: 2007072014024600
Modified files:
rpm/build parsePrep.c
Log:
grr, stoopid trailing '/' on directories. perhaps %{?foo/}
expansion?
Having embarrassed myself with Yet Another Corner Case, the attached
patch permits the rather clunky
%{?_dirpath:%{_dirpath}/file}
to be written more compactly (and readably) as
%{?_dirpath/file}
What I don't know is whether I should continue tricking up macro syntax.
If more macro syntax is desired, then I will also push the lazy mkdir's
into macro.c with syntax like
%{?mkdir:%{?_dirpath/}}
because the corner case handling within rpmlib is rather tedious and
clunky and
the code paths on which lazy mkdir's are attempted are likely gonna
break when
code is re-arranged.
What say ye?
73 de Jeff
mappend.patch
Description: Binary data
Re: [CVS] RPM: rpm/build/ parsePrep.c
On Fri, Jul 20, 2007, Jeff Johnson wrote:
On Jul 20, 2007, at 9:02 AM, Jeff Johnson wrote:
grr, stoopid trailing '/' on directories. perhaps %{?foo/} expansion?
Having embarrassed myself with Yet Another Corner Case, the attached
patch permits the rather clunky
%{?_dirpath:%{_dirpath}/file}
to be written more compactly (and readably) as
%{?_dirpath/file}
What I don't know is whether I should continue tricking up macro syntax.
In general I want to see more powerful macro expansion, but I recommend
to make the syntax more orthogonal and extensible. For instance, in
your above example the / really means just a slash. Also, as for
each feature a separating character after the macro name is required
and only a few character are available in ASCII one also visuably
recognized as such, I recommend to do use a more generalized syntax
and make the particular path extension just a special case of a
string extension. For instance, let's say + is generic operator for
string extension/concatenation then you can achieve your example with
%{?_dirpath+/foo} and still support other ways of extensions, too.
What say ye?
A few years ago we I've developed in the OSSP project a C library
named OSSP var (http://www.ossp.org/pkg/lib/var/) which IMHO uses
a orthogonal and flexible enough syntax and is also implemented
with a robust recursive descent parser which supports full nesting,
array expansions, multi-line matching, _custom_ operations, etc.
The best for you is: its array expansion uses the RPM query format
syntax [...] :-) If you want to be inspired have a look at:
http://www.ossp.org/man/man.cgi/pkg/lib/var/var.pod and especially at
the end under EXAMPLE (USER). Perhaps you find it as cool as I do. I
especially like the custom operations...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/build/ parsePrep.c
On Jul 20, 2007, at 11:56 AM, Ralf S. Engelschall wrote:
On Fri, Jul 20, 2007, Jeff Johnson wrote:
On Jul 20, 2007, at 9:02 AM, Jeff Johnson wrote:
grr, stoopid trailing '/' on directories. perhaps %{?foo/}
expansion?
Having embarrassed myself with Yet Another Corner Case, the attached
patch permits the rather clunky
%{?_dirpath:%{_dirpath}/file}
to be written more compactly (and readably) as
%{?_dirpath/file}
What I don't know is whether I should continue tricking up macro
syntax.
In general I want to see more powerful macro expansion, but I
recommend
to make the syntax more orthogonal and extensible. For instance, in
your above example the / really means just a slash. Also, as for
each feature a separating character after the macro name is required
and only a few character are available in ASCII one also visuably
recognized as such, I recommend to do use a more generalized syntax
and make the particular path extension just a special case of a
string extension. For instance, let's say + is generic operator
for
string extension/concatenation then you can achieve your example
with
%{?_dirpath+/foo} and still support other ways of extensions, too.
I have my answer, check-in shortly. I expect the change to be short-
lived.
What say ye?
A few years ago we I've developed in the OSSP project a C library
named OSSP var (http://www.ossp.org/pkg/lib/var/) which IMHO uses
a orthogonal and flexible enough syntax and is also implemented
with a robust recursive descent parser which supports full nesting,
array expansions, multi-line matching, _custom_ operations, etc.
The best for you is: its array expansion uses the RPM query format
syntax [...] :-) If you want to be inspired have a look at:
http://www.ossp.org/man/man.cgi/pkg/lib/var/var.pod and especially at
the end under EXAMPLE (USER). Perhaps you find it as cool as I do. I
especially like the custom operations...
I question whether that amount of flexibility is useful or needed.
The design goal of
macros was to unify CLI options, rpm configuration, and spec file
syntax.
That goal was achieved quite well with a rather modest implementation.
Specific non-design goals were to change to Yet Another Scripting
Language.
There are any number of better choices for string whacking than macro
expansions.
The current usage cases for macros in spec files are quite
disturbing, and need to be
eliminated, or otherwise simplified, not enhanced imho. Further
complexity
with a grammar-less spec file syntax will only fuel expectations, and
cannot
possibly succeed reliably and predictably. Go add some '\r'
characters to
a spec file and watch what breaks.
The largest incompatibilities with claims that *.rpm files are vendor-
specific are
also due to vendor macro usage.
But since everything else in rpm is on the table, why not rip the
current macro
implementation as well?
73 de Jeff
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/build/ parsePrep.c
But since everything else in rpm is on the table, why not rip the current macro implementation as well? I'd be in favor of something that a) has a defined and verifiable grammar, and b) doesn't hurt my eyes with complex operations. :-) Way back when I thought xmlspec was headed in that direction, though I have no clue whether xml or yaml or *ml is really the right way to handle the problem. Is there something that could be used as a possible reference or starting point in that regard? Jason __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/build/ parsePrep.c
On Jul 20, 2007, at 2:10 PM, Jason Corley wrote: But since everything else in rpm is on the table, why not rip the current macro implementation as well? I'd be in favor of something that a) has a defined and verifiable grammar, and b) doesn't hurt my eyes with complex operations. :-) Way back when I thought xmlspec was headed in that direction, though I have no clue whether xml or yaml or *ml is really the right way to handle the problem. Is there something that could be used as a possible reference or starting point in that regard? Well, there are actually two different items being addressed: 1) general current *.spec syntax 2) the macro specific implementation Macros have a rather narrow syntax and mostly have a verifiable grammar. The usage cases of macros never have to be eye-scratching, one can quite easily embed messy constructs into higher level, and cleaner, constructs. How and where macros are used is a different problem. There are not well-defined expansion points, which is esssentially what forces the warty rule Macros are expanded wherever they are found, inside strings, on false branches of %if (since fixed in other ways, %if is no macro), etc, etc. And lusers insist on macroizing every bleeping thing under the Sun because its cool! As for the current spec file parser, what needs to happen is to walk slowly and carefully away from something that cannot be saved. The existing spec file parser *MUST* continue because there's way too much that depends on the existing paradigm. Lusers keep asking for featlets bugtures, the most recent featlet request is arbitrary tags and sections. Meanwhile, existing spec files are almost YAML, certainly can be made so if the indentation can be automated, and, say, certain section markers can be rewritten from %description Popt is a C library for parsing command line parameters. Popt was heavily influenced by the getopt() and getopt_long() functions, but it improves on them by allowing more powerful argument expansion. Popt can parse arbitrary argv[] style arrays and automatically set variables based on command line arguments. Popt allows command line arguments to be aliased via configuration files and includes utility functions for parsing arbitrary strings into argv[] arrays using shell-like rules. Install popt if you're a C programmer and you'd like to use its capabilities. to Description: |- Popt is a C library for parsing command line parameters. Popt was heavily influenced by the getopt() and getopt_long() functions, but it improves on them by allowing more powerful argument expansion. Popt can parse arbitrary argv[] style arrays and automatically set variables based on command line arguments. Popt allows command line arguments to be aliased via configuration files and includes utility functions for parsing arbitrary strings into argv[] arrays using shell-like rules. Install popt if you're a C programmer and you'd like to use its capabilities. See the recent %patchNN - %patch -P NN rewrite for the sneakily adiabatic proof-of-concept of rewriting spec files on the fly. And I'm not quite ready to try to find out where libyaml is gonna end up using RPM_CHECK_LIB(). Here's today's problem: rpm -q --yaml popt | more rpm: symbol lookup error: /usr/lib/librpmdb-5.0.so: undefined symbol: db_create_rpmdb I likely forgot make distclean shrug hth 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/build/ parsePrep.c
%__tar instead of %_tarbin. I fixed that but haven't checked in.
73 de Jeff
On Jul 2, 2007, at 8:55 PM, Mark Hatle wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org Name: Mark Hatle
Root: /v/rpm/cvs Email: [EMAIL PROTECTED]
Module: rpm Date: 03-Jul-2007
02:55:40
Branch: HEAD Handle: 2007070301553900
Modified files:
rpm/build parsePrep.c
Log:
the value of tar is freed later on. Which causes a problem.
strdup
makes sure that it's freeable.
Summary:
RevisionChanges Path
2.76+1 -1 rpm/build/parsePrep.c
__
__
patch -p0 '@@ .'
Index: rpm/build/parsePrep.c
==
==
$ cvs diff -u -r2.75 -r2.76 parsePrep.c
--- rpm/build/parsePrep.c 21 Jun 2007 18:58:05 - 2.75
+++ rpm/build/parsePrep.c 3 Jul 2007 00:55:39 - 2.76
@@ -240,7 +240,7 @@
tar = rpmGetPath(%{_tarbin}, NULL);
if (strcmp(tar, %{_tarbin}) == 0)
-tar = tar;
+tar = xstrdup(tar);
if (compressed != COMPRESSED_NOT) {
const char *zipper;
@@ .
__
RPM Package Managerhttp://rpm5.org
CVS Sources Repository[EMAIL PROTECTED]
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
