tests/mongo & tests/gpsee missing in HEAD & rpm-5_3
forgot to import to cvs? -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: tests/mongo & tests/gpsee missing in HEAD & rpm-5_3
2010/9/30 Jeff Johnson : > > On Sep 30, 2010, at 1:09 PM, Per Øyvind Karlsen wrote: > >> forgot to import to cvs? >> > > Nope: > [...@rhel6 tests]$ cvs add mongo > cvs [add aborted]: there is a version in mongo already > [...@rhel6 tests]$ cvs add gpsee > cvs [add aborted]: there is a version in gpsee already > > Try > cvs up -d tests d'oh, yeah, there they are. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/lib/ Makefile.am
2010/10/1 Jeff Johnson : > Fixing the other way -- by removing from lib/rpmts.h -- > is the fix going forward. > > Exposing headers just leads to complaints about rpm's lack of API/ABI. > The only achievable solution there is to _NOT_ export anything > new until its fully > finalized/finished/lockedin/reliable/neededdocumented/whatever Oh, okay, I > thought it was intended to be exported as it was added, I'll fix it then. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ rpmfc.c
2010/10/19 Jeff Johnson : > Ick. Under a #ifdef and write the blueprint please. See scripts/pythoneggs.py for now, I'm off to bed... ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ rpmfc.c
2010/10/19 Jeff Johnson : > > On Oct 18, 2010, at 10:49 PM, Per Øyvind Karlsen wrote: > >> 2010/10/19 Jeff Johnson : >>> Ick. Under a #ifdef and write the blueprint please. >> See scripts/pythoneggs.py for now, I'm off to bed... ;) >> > > Seen. ANd will be reverted until a blueprint is written. Hm, I guess from reading the other thread about suggests etc. that the issue is that I used suggests over requires(hint) etc.? Used out of ignorance and due to adoption in Mandriva, I wasn't fully aware of the situation, I'll create a blueprint for it and also start looking into replacing Suggests usage in urpmi. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/rpmdb/ rpmdb.c
2010/11/1 Jeff Johnson :
> Could you put this under a
> #ifdef RPM_VENDOR_MANDRIVA
> please?
>
> There's a far far deeper issue here, related to whether _ALL_
> rpm queries should explicitly indicate NOTFOUND (like "(none)")
> or whether "best effort" as in implictly assuming that
> anything not reported can be assumed to not exist, that needs
> to be soretd through.
>
> In 1998, when RPM from the CLI was the only means to install
> packages, it was _ABSOLUTELY_ necessary to supply additional
> explicit hints on stdout/stderr (yet another related issue related to
> less/more piping)
> like "(none)".
>
> The answer these days is much less clear:
> All explicit markers like "(none)" in output queries used
> for other purposes MUST be filtered.
>
> And finally there's the additional design flaw (specific to Mandriva) or
> Provides: /path/to/file
> The proper index is Basenames/Filepaths, not Providename, for all tokens that
> start with '/'. Its bad craziness to just splatter database entries into
> multiple indices because multiple indices must _ALWAYS_ be searched
> Just In Case.
>
> The above is the reasoning for the request to add
> #ifdef RPM_VENDOR_MANDRIVA
> which, because of the Mandriva packaging choice to use
> Provides: /path/to/file
> to minimize the createrepo-like metadata spewage used by Mandriva, is
> _ABSOLUTELY_ the correct fix.
>
> But only for Mandriva.
But you still get the same behaviour for other distros.
In rpmdb.c:694
qva->qva_mi = rpmtsInitIterator(ts, RPMTAG_FILEPATHS, fn, 0);
if (qva->qva_mi == NULL && !provides_checked && !gotpattern)
qva->qva_mi = rpmtsInitIterator(ts, RPMTAG_PROVIDENAME, fn, 0);
if (qva->qva_mi == NULL) {
struct stat sb;
if (!gotpattern && Lstat(fn, &sb) != 0)
rpmlog(RPMLOG_NOTICE, _("file %s: %s\n"), fn, strerror(errno));
...
I was first wondering if checking with 'rpmmiCount(qva->qva_mi) == 0'
(rpmtsInitIterator(ts, RPMTAG_PROVIDENAME, fn, 0) doesn't return NULL
unless my change is done) in addition, but doing the change I did
seemed more consistent with existing behaviour.
Am I missing something? :o)
I guess file dependencies etc. is something I'll eventually add for
parent directory & symlink dependencies later on in Mandriva..
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Packaging of %included files
Is there any way to ship files to be %included that's more convenient
than the following:
Source1: somestuff
%include %{SOURCE1}
The problem with this is that if the spec file is queried without the
correct %_sourcedir set, it will fail.
If one could do something like 'Source1: %{_specdir}/somestuff' and
that would result in it being packaged in %_specdir rather than
%_sourcedir, that would be convenient.
Is there any ways to solve this currently? Would it be sane to
implement something like this?
What is recommended practice for use of %include?
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/scripts/ dbconvert.sh
Could you verify and make any appropriate modifications to it, and
also integrate the one referred to (if necessar/possible/relevant?) in
the mail with Shlomi?
Then I'll upload a new version to cooker. :)
2010/11/11 Per Ųyvind Karlsen :
> RPM Package Manager, CVS Repository
> http://rpm5.org/cvs/
>
>
> Server: rpm5.org Name: Per Ųyvind Karlsen
> Root: /v/rpm/cvs Email: pkarl...@rpm5.org
> Module: rpm Date: 11-Nov-2010 22:14:09
> Branch: HEAD Handle: 201021140900
>
> Added files:
> rpm/scripts dbconvert.sh
> Modified files:
> rpm CHANGES
>
> Log:
> add a first prototype scripts/dbconvert.sh for handling rpmdb
> conversion during upgrades.
>
> Summary:
> Revision Changes Path
> 1.3494 +2 -0 rpm/CHANGES
> 1.1 +139 -0 rpm/scripts/dbconvert.sh
>
>
> patch -p0 <<'@@ .'
> Index: rpm/CHANGES
>
> $ cvs diff -u -r1.3493 -r1.3494 CHANGES
> --- rpm/CHANGES 3 Nov 2010 14:07:35 - 1.3493
> +++ rpm/CHANGES 11 Nov 2010 21:14:09 - 1.3494
> @@ -1,4 +1,6 @@
> 5.3.5 -> 5.4a1:
> + - proyvind: add a first prototype scripts/dbconvert.sh for handling
> rpmdb
> + conversion during upgrades.
> - jbj: rpmdb: double the defaults for locking tunables.
> - jbj: rpmdb: fix: don't bother excluding RPM_CHAR_TYPE sanity check.
> - jbj: rpmdb: fix: don't bother converting to RPM_UINT8_TYPE.
> @@ .
> patch -p0 <<'@@ .'
> Index: rpm/scripts/dbconvert.sh
>
> $ cvs diff -u -r0 -r1.1 dbconvert.sh
> --- /dev/null 2010-11-11 22:11:01.0 +0100
> +++ dbconvert.sh 2010-11-11 22:14:09.227464410 +0100
> @@ -0,0 +1,139 @@
> +TIMESTAMP="$(LC_TIME=C date -u +%F_%R)"
> +BACKUP="/var/tmp/rpmdb-$TIMESTAMP"
> +OLDDB="/var/tmp/olddb"
> +DBPATH="${DBPATH:-/var/lib/rpm}"
> +
> +DB_DUMP="$(which db51_dump 2> /dev/null)"
> +if [ -z "$DB_DUMP" -a ! -x "$DB_DUMP" ]; then
> + DB_DUMP="$(which db_dump 2> /dev/null)"
> +fi
> +if [ -x "$DB_DUMP" ]; then
> + echo "Found $DB_DUMP"
> +else
> + echo "Unable to locate db_dump"
> + exit 1
> +fi
> +
> +DB_DUMP_VERSION="$($DB_DUMP -V |sed 's/^Berkeley DB
> \([0-9]\+\.[0-9]\+\).*/\1/')"
> +if [ "$DB_DUMP_VERSION" == 5.1 ]; then
> + echo "$DB_DUMP version $DB_DUMP_VERSION ok"
> +else
> + echo "Incompatible db_dump version ($DB_DUMP_VERSION) found, 5.1.*
> required"
> + exit 1
> +fi
> +
> +DB_LOAD="$(which db51_load 2> /dev/null)"
> +if [ -z "$DB_LOAD" -a ! -x "$DB_LOAD" ]; then
> + DB_LOAD="$(which db_load 2> /dev/null)"
> +fi
> +if [ -x "$DB_LOAD" ]; then
> + echo "Found $DB_LOAD"
> +else
> + echo "Unable to locate db_load"
> + exit 1
> +fi
> +
> +DB_LOAD_VERSION="$($DB_LOAD -V |sed 's/^Berkeley DB
> \([0-9]\+\.[0-9]\+\).*/\1/')"
> +if [ "$DB_LOAD_VERSION" == 5.1 ]; then
> + echo "$DB_LOAD version $DB_LOAD_VERSION ok"
> +else
> + echo "Incompatible db_load version ($DB_LOAD_VERSION) found, 5.1.*
> required"
> + exit 1
> +fi
> +
> +echo "Converting system database."
> +rm -rf $OLDDB
> +mkdir -p {$OLDDB,$DBPATH}/{log,tmp}
> +if [ "$DBPATH" != "/var/lib/rpm" ]; then
> + if [ -f /var/lib/rpm/DB_CONFIG ]; then
> + cp /var/lib/rpm/DB_CONFIG $DBPATH/DB_CONFIG
> + else
> + tee $DBPATH/DB_CONFIG << EOH
> +# Environment
> +#add_data_dir .
> +set_data_dir .
> +set_create_dir .
> +set_lg_dir ./log
> +set_tmp_dir ./tmp
> +
> +# -- thread_count must be >= 8
> +set_thread_count 64
> +
> +#set_verbose DB_VERB_DEADLOCK
> +#set_verbose DB_VERB_FILEOPS
> +#set_verbose DB_VERB_FILEOPS_ALL
> +#set_verbose DB_VERB_RECOVERY
> +#set_verbose DB_VERB_REGISTER
> +#set_verbose DB_VERB_REPLICATION
> +#set_verbose DB_VERB_REP_ELECT
> +#set_verbose DB_VERB_REP_LEASE
> +#set_verbose DB_VERB_REP_MISC
> +#set_verbose DB_VERB_REP_MSGS
> +#set_verbose DB_VERB_REP_SYNC
> +#set_verbose DB_VERB_REP_TEST
> +#set_verbose DB_VERB_REPMGR_CONNFAIL
> +#set_verbose DB_VERB_REPMGR_MISC
> +#set_verbose DB_VERB_WAITSFOR
> +
> +# Logging
> +
> +# Memory Pool
> +#XXX initializing dbenv with set_cachesize has unimplemented prerequsites
> +#set_cachesize 0 1048576 0
> +set_mp_mmapsize 16777216
> +
> +# Locking
> +set_lk_max_locks 16384
> +set_lk_max_lockers 16384
>
Re: [CVS] RPM: rpm/ CHANGES rpm/scripts/ dbconvert.sh
2010/11/11 Jeff Johnson : > > On Nov 11, 2010, at 4:24 PM, Per Øyvind Karlsen wrote: > >> Could you verify and make any appropriate modifications to it, and >> also integrate the one referred to (if necessar/possible/relevant?) in >> the mail with Shlomi? >> >> Then I'll upload a new version to cooker. :) > > Hint: Watch the buildbot's ... next time its you, not me, who does the change. Didn't get the hint.. :/ -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Fwd: Hi!
I've finally gotten around to rewrite apt-rpm from caixa's branch to the native rpm5 api now, so for anyone who's interested, it can be found at: http://gitorious.org/rpm5distro/apt-rpm For testing, I must admit I haven't had the time, so I leave it up to anyone with the interest. ;) rpm >= 5.3 required -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [Apt-Rpm] Fwd: Hi!
2010/11/17 John Thomson : > Hi Per Øyvind, > Long time since we last spoke. > Hope everything is going well for you. > > I have a vm with rpm 5.3.1 on it and will try and see if apt-rpm works > with it. It definitely will help in terms of speeding up the testing and > possible deployment stages. Notice that we're in the process of switching to rpm 5.3.6 in cooker now, so you might find those packages in main/testing for cooker of interest. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Fwd: Hi!
2010/11/17 Per Øyvind Karlsen : > I've finally gotten around to rewrite apt-rpm from caixa's branch to > the native rpm5 api now, so for anyone who's interested, it can be > found at: > http://gitorious.org/rpm5distro/apt-rpm > > For testing, I must admit I haven't had the time, so I leave it up to > anyone with the interest. ;) > > rpm >= 5.3 required FYI: I just pushed a fix for unsatisfied rpmlib() dependencies, there's some similark, but less frequent ones for interpreters etc. as well which I'll have to resolve some time later... -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/perl/ Makefile.am RPM.pm RPM.xs r...
2010/12/2 Jeff Johnson :
>
> Ok, let's start with the key utils preliminarties ...
> ... this crap from RPM4 needs to go away soonestly.
>
> This code needs to be disappeared and replaced to use keyutils afaict:
>
> +sub getpasswdfile {
> + my ($self) = @_;
> + $self->{password_file} or return 1;
> + open(my $hpass, "<", $self->{password_file}) or return 0;
> + $self->{passphrase} = <$hpass>;
> + chomp($self->{passphrase});
> + close($hpass);
> + 1;
> +}
>
> See rpmio/rpmku.c for the replacement.
>
> The implementation with keyutils is rather subtle.
>
> If --with-keyutils is in AutoFu, what is returned from rpmku*
> is the name ("rpm:passwd") of the keyutils item rather than the
> password string.
>
> The benefit of keyutils is that the password is NOT resident
> in RPM's address space except when absolutely necessary.
>
> The additional benefit is that the password access and duration
> is handled by keyutils, not RPM (and rpm-perl methods).
>
> Read up on keyutils, the best source of how to use is
> the README in the source code.
k, thx for the pointer, will read up on. :)
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/perl/t/ 10.sign.t
2010/12/2 Jeff Johnson : > Don't forget > #ifdef RPM_VENDOR_MANDRIVA > please. > > Or talk to me about using keyutils and generate/sign > methods. The perl changes for importing and signing > aren't maintainable going forward. k, will add, just gotta figger out best way first.. I don't think I have that many functions left missing anyhow that's in use by our tools, revisiting all of them will be done. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
parsing hdlists with rpmgi?
Quoting from mdvbz#61690: " Comment #13 From Jeff Johnson on 2010-11-17 16:47:34 CEST (-) [reply] Does URPM still need to parse HDLISTS? Perfectly OKAY if so, just, well no other distro needs/wants hdlists any more. There's code in lib/rpmgi.c in RPM that iterates across hdlists that could be ripped out if there's no further usage case for hdlists in Mandriva ... Comment #14 From Jeff Johnson on 2010-11-17 16:50:44 CEST (-) [reply] And if you _DO_ still need hdlists, then rpmgi is far far simpler to get at hdlists than what is in URPM.xs. Ther are other reasons to bind rpmgi directly into URPM too, its not just hdlist interation, but also full (and multiply rooted) file tree walks, including through http:// and ftp::// URI's, and also arglist and rpmdb iterators that are captured into the rpmgi "Generalized Iterator") interface. " I seem to have managed to bust hdlist parsing in URPM anyways, so switching to use rpmgi for parsing it might be a quick and feasible fix, but rpmgi isn't part of the exported API, so how would I do this? Quick code sample provided would be greatly appreciated, I've been trying to look at code in rpm, but somehow my attempts to achieve the same fails.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: parsing hdlists with rpmgi?
2010/12/5 Jeff Johnson : > Do you have a hdlist that I can use? If you can give ma a pointer, > I can rapidly write up specific usage details, and suggest what > might be done through URPM.xs. ftp://ftp.free.fr/.mirrors9/ftp.mandriva.com/MandrivaLinux/devel/cooker/x86_64/media/main/testing/media_info/hdlist.cz -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm doesn't build --with-ruby (on HEAD and rpm-5_4)
2010/12/7 Eric MSP Veith : > Am Dienstag, 7. Dezember 2010, 04:43:10 schrieb Jeff Johnson: >> Talk to Per Oyvind if its the rpm-5_3 you want to change. rpm-5_4 is the >> same as HEAD, including your changes from this weekend. > > Per, do I have your permission? Or, more appropriately, do you want to merge > the corresponding changes from HEAD? Basically, it's about the following > patch: Sure! I pretty much don't have any focus on nor care for ruby support in rpm currently, so I'd rely on you being the better judge on and being in a position for making decissions for ruby anyways.. :) (aka: do as you please, asking later for my permission again is most likely to be rather redundant..;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
exporting rpmbf.h & rpmgi.h to public API?
Should/could we have rpmbf.h & rpmgi.h installed as system headers? -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: exporting rpmbf.h & rpmgi.h to public API?
2010/12/9 Jeff Johnson :
>
> On Dec 9, 2010, at 3:03 PM, Per Øyvind Karlsen wrote:
>
>> Should/could we have rpmbf.h & rpmgi.h installed as system headers?
>>
>
> Go for it.
>
> RPM goes through predictable cycles ... export ... import ... export ...
> depending on whether users are complaining
> RPM doesn't have a stable API!
> Yes, RPM does not gave, nor has ever had, a stable API.
>
> A stable API/ABI has also never been promised, see
> the version in RPM library names, the rest is a
> simple deduction.
>
> rpmbf.h won't hurt a thing. rpmgi.h still may need a bit of work,
> but the API itself is unlikely to change.
>
> Did you ever figger hdlists using rpmgi.h? I stopped looking
> for the reasons stated.
nah, not really, I tried tying the following into the code:
rpmRC rpmrc = RPMRC_NOTFOUND;
rpmts ts = rpmtsCreate();
rpmtsSetRootDir(ts, NULL);
rpmgi gi = rpmgiNew(ts, RPMDBI_HDLIST, NULL, 0);
gi->active = 1;
gi->fd = fd;
while ((rpmrc = rpmgiNext(gi)) == RPMRC_OK) {
Header h;
h = rpmgiHeader(gi);
if (h == NULL) /* XXX perhaps stricter break instead?
*/
continue;
else
fprintf(stderr, "gi: %s\n", get_nvra(h));
}
}
which pretty much left me with the same behaviour:
error: rpmpkgRead: Header: Header V3 DSA signature: UNKNOWN, key ID 26752624
Haven't debugged it much further since..
Btw. you hinted at the use of bloom filter in URPM.xs earlier, could
you provide me with a pointer on where in the code? (I still lack full
understanding of all the details and what things do exactly what,
while you with better knowledge of the rpm and pretty much everything
else wrt. rpm to easily spot use cases in the code for it. ;)
..
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: exporting rpmbf.h & rpmgi.h to public API?
2010/12/10 Jeff Johnson :
>
> On Dec 9, 2010, at 6:33 PM, Per Øyvind Karlsen wrote:
>
>> 2010/12/9 Jeff Johnson :
>>>
>>> On Dec 9, 2010, at 3:03 PM, Per Øyvind Karlsen wrote:
>>>
>>>> Should/could we have rpmbf.h & rpmgi.h installed as system headers?
>>>>
>>>
>>> Go for it.
>>>
>>> RPM goes through predictable cycles ... export ... import ... export ...
>>> depending on whether users are complaining
>>> RPM doesn't have a stable API!
>>> Yes, RPM does not gave, nor has ever had, a stable API.
>>>
>>> A stable API/ABI has also never been promised, see
>>> the version in RPM library names, the rest is a
>>> simple deduction.
>>>
>>> rpmbf.h won't hurt a thing. rpmgi.h still may need a bit of work,
>>> but the API itself is unlikely to change.
>>>
>>> Did you ever figger hdlists using rpmgi.h? I stopped looking
>>> for the reasons stated.
>> nah, not really, I tried tying the following into the code:
>> rpmRC rpmrc = RPMRC_NOTFOUND;
>> rpmts ts = rpmtsCreate();
>> rpmtsSetRootDir(ts, NULL);
>> rpmgi gi = rpmgiNew(ts, RPMDBI_HDLIST, NULL, 0);
>>
>> gi->active = 1;
>> gi->fd = fd;
>> while ((rpmrc = rpmgiNext(gi)) == RPMRC_OK) {
>> Header h;
>>
>> h = rpmgiHeader(gi);
>> if (h == NULL) /* XXX perhaps stricter break instead?
>> */
>> continue;
>> else
>> fprintf(stderr, "gi: %s\n", get_nvra(h));
>> }
>>
>> }
>>
>> which pretty much left me with the same behaviour:
>> error: rpmpkgRead: Header: Header V3 DSA signature: UNKNOWN, key ID 26752624
>>
>
> Do the same as --nosignatures, lemme know how much further you
> get.
>
> I saw the same behavior with --nosignature. What I don't
> understand is the *.cz and other issues. If all
> of that is working for you, I'll figger the problem
> with signatures on headers in hdlists.
>
> Hmmm ... what I know as a hdlist could NEVER have header
> signatures or digests because its a metadata header with
> information removed. What I saw in perl-URPM was also
> removing info (but commented out).
Ahh,, yes, _RPMVSF_NODIGESTS made it work, although the final
element gave 'error: rpmpkgRead: Header: (null)', but probably trivial
to fix, will look into later (bed time for me now). :)
>
> So I suspect that what I implemented in rpmgi isn't what
> Mandriva is calling "hdlists".
>
>
>
>> Haven't debugged it much further since..
>>
>> Btw. you hinted at the use of bloom filter in URPM.xs earlier, could
>> you provide me with a pointer on where in the code? (I still lack full
>> understanding of all the details and what things do exactly what,
>> while you with better knowledge of the rpm and pretty much everything
>> else wrt. rpm to easily spot use cases in the code for it. ;)
>>
>
> I've forgotten, remind me.
https://qa.mandriva.com/show_bug.cgi?id=61690#c12
>
> WikiPedia is pretty good at Bloom filters. tdict.c (in popt) is
> a pretty easy way to get up to speed on coding (names are different,
> routines are the same).
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
rpmtsSetNotifyCallback()?
(quoting https://qa.mandriva.com/show_bug.cgi?id=61690#c15) Comment #15 From Jeff Johnson on 2010-11-17 16:55:34 CEST (-) [reply] There's this rpmts "setter" that should be wired up /** \ingroup rpmts * Set dependency solver callback. * @param tstransaction set * @param (*solve) dependency solver callback * @param solveData dependency solver callback data (opaque) * @return 0 on success */ int rpmtsSetSolveCallback(rpmts ts, int (*solve) (rpmts ts, rpmds ds, const void * data), const void * solveData) /*...@modifies ts @*/; Hint: MongoDB will be attached through the "solve database" callback. And likely most of URPM's depsolving could be done more efficiently if the rpmtsCheck() SolveCallback() were used intelligently. Could you provide a bit more detailed/specific hint on how/where? :) I'm currently looking into some various callback related issues in URPM, and it's a new territory for me to get intimate with and fully grasp.. By the looks of the current code in URPM.xs, it does kinda look kinda dated, hard to read and understand right away, suspecting that parts of it being broken making it not easier to wrap my head around the whole thing.. So could you tell me where exactly in the code you're referring to, with an example on how to implement, or a pointer to some easy to understand example elsewhere? If spotted some clearly fudged code that I should be aware of and that really needs to be fixed, that I guess would be the most important though, stabbing around in the dark on unstable ground easily gets a bit tedious.. I'm sure I'll probably be capable of figuring these things by myself, but some hints will help get me there faster, proceed with the switch faster with less hazzle & resulting FUD, and allow us to start focus on development and time to invest in discussions around it again. :o) I'll try get some overview the best I can meanwhile, just suspecting that my efficiency could do better.. ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ rpmts.c
2010/12/14 Jeff Johnson :
> Um, maybe.
>
> As a C programmer, sure: initializing NULL pointers to "" is useless.
>
> But when you start to look at missing values for zillions of
> strings passed through multiple paths, to bindings, and in databases,
> well,
> We'll see.
>
> E.g. the file path "/" is represented in an rpmdb as '\0' with a len of 1.
>
> And you surely know the other places in rpmvercmp replacements where
> missing values are initialized to "" because the code is adjacent to
> DistEpoch: drilling.
>
> So the programming practice everywhere has been to treat all of
> NULL
> ""
> and other semantic meanings for "missing" as equivalent.
>
> Care to wager whether the change causes an issue? The issue
> will be a segfault and an instant FULLSTOP fix-and-release exercise.
Ouch, yes, headache on this shit again reoccuring.. ;)
Would perhaps just let it fall through without the return after
setting rootDir to "" if argument is NULL be the most reliable and
least complex fix?
if (rootDir == NULL) {
ts->rootDir = xstrdup("");
}
rootLen = strlen(rootDir);
/* Make sure that rootDir has trailing / */
if (!(rootLen && rootDir[rootLen - 1] == '/')) {
char * t = alloca(rootLen + 2);
*t = '\0';
(void) stpcpy( stpcpy(t, rootDir), "/");
rootDir = t;
}
This way you'd always know that the default rootDir must be "/"
regardless of NULL, "" or "/" being passed as the argument and would
make the different checks for rootDir on this less complex. Ie.
currently there's various forms similar to this: (rootDir == NULL ||
(rootDir && (rootDir[0] == '\0' || (rootDir[0] == '/' && rootDir[1] ==
'/') that all would have to be done to reliably establish rootDir
really being the default "/", which from what I've seen now and also
earlier in the past the chance for letting one of those slip may
happen too easy (ie. as it did in (at least) psm.c and
filetriggers.c)...
This would at least preserve compatibility with the two arguments "" &
NULL currently being used to set it to default and avoid the necessity
for checking all possibilities, only having one consistent and always
predictable string to check for. :)
I probably would've done that myself in stead in the commit, if it
weren't for the 'ts->rootDir = xstrdup("");' being under a #ifndef
DYING, drawing the conclusion that the "" were meant to be removed
eventually..
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ rpmts.c
2010/12/14 Jeff Johnson : > > On Dec 14, 2010, at 7:44 AM, Jeff Johnson wrote: > >>> >>> 5.3.6 -> 5.3.7: >>> + - proyvind: rpmts: don't default rootDir to "" if set to NULL, as it >>> + confusing rpm checks on NULL & "/" only, without "", making ie. >>> + %posttrans scriptlets fail where NULL is used (mdvbz#61696). > > THere's another semantic definition here that hasn't ever been thought > through: > > Should %posttrans from erased packages be run? Good question, I earlier found myself wondering about this as my assumption on there being a %posttransun turned out to be nothing more than an assumption.. ;p Also from the little I played around with it, I wasn't able to find some similar way to determine what action had taken place for the scriptlet to know and be able to act based on(?), such as one can with %post/%pre/%postun/%preun.. Touching scriptlets and filetriggers again, now I think it's a more appropriate time to revisit your file trigger implementation again and start thinking about at deprecating the #ifdef'ed mandriva filetrigger implementation which simply isn't flexible enough to fir all the different needs for point in time (%pre/%post/%preun/%postun/%posttrans..) where the trigger might need to be run at... > > There are implementation details why the definition has not been finalized. > > But its also not clear whether an erased package should be permitted > to have a side effect after a package has been removed, and all its > contents have gone away. This is the "NO" reasoning. > > OTOH, state machine symmetry leads to exactly the opposite "YES" answer. I guess the experience with it of my own described above might be of help in determining a proper reasoning, beyond that I'm without any answers for this one, but if a %posttransun would be possible without some obvious caveats I expect that I'm missing, that could be a solution where the "NO" reasoning should be acceptable for most as the "YES" would be rather satisfied by a %posttransun which would make the current state clear and also provide one with an intuitively, consistently named convention satisfying luser expectations and satisfaction. My insight on the matter is mainly from rpm packaging perspective, rather than rpm engineering itself on this though, so the understanding of the topic is obviously rather incomplete. ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Metadata size constraints wrt. parentdir & symlink deps, Was: [CVS] RPM: rpm/ CHANGES rpm/lib/ rpmts.c
2010/12/14 Jeff Johnson : > > On Dec 14, 2010, at 12:47 PM, Per Øyvind Karlsen wrote: > >> >> My insight on the matter is mainly from rpm packaging perspective, >> rather than rpm engineering itself on this though, so the >> understanding of the topic is obviously rather incomplete. ;) >> > > This is a pragmatic expectation. Noone has ever reported > a compelling usage case for %posttrans from erased packages. > > Note that Tresys "collections" and the hat trick of security > frameworks using helpers, and the recently added triple of > OrderByRequires: (or whatever @rpm.org chose to name the tag), > and other fiddle ups coming in rpm-4.9.0 alpha -> beta -> ... > are all gonna impact (dare I say "train wreck"?) RPM's > state machine over the next year or so. > > Too early to tell what is gonna be needed. Easy enough to add > whatever & whenever, I have no desire to lead the > Safer! Securer! Obscurer! > cheer leading, I'd rather watch the ball in play ;-) Ouch, yeah, I didn't really feel very compelled in jumping in on that one, much less interest in putting efforts into adopting such.. On a related note though I've started giving parentdir & symlink deps some more thoughts again though, skimming the surface on practical issues and drawbacks of such as ie. the size of files.xml.lzma in main/release currently being 3736704 bytes compared to the gzip compressed synthesis.hdlist.cz being as small as 775230 bytes (if switching to xz compression, size could be trimmed down ~30% further), so something more optimal than requiring this metadata which currently for a single repository alone is bigger in size than the sum of synthesis for all repos together. The necessary cleaning implied by stricter policies on ownership and getting rid of all the incorrectly multiple owned directories might improve it marginally, putting some thinking into the format of the metadata (with something as repetetive data as lists of paths are, I bet there must be some room for improval utilizing this knowledge about the data to compress) might improve things a bit as well, but deltas are the only known solution to worthwile size reduction gains to at least reducing the pain of having to download large metadata files with minimal changes between frequently when being on a rolling distro such as ie. cooker, although putting maintenance headaches of maintaining several deltas for it to work (bundling several deltas into some indexed revision history to match against older revisions of the metadata could perhaps be an idea to make things slightly less messy perhaps?). Just some thoughts of mine, I bet others has put a lot more thinking with more actual insight, knowledge and even experience on the matters, I'd love to hear others' thoughts on the matter, with perhaps some suggestions and ideas to look into when getting there.. Olivier & Giuseppe, I CC'ed you two as I know these are fields which you both has/had some interest in at least on some level. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Metadata size constraints wrt. parentdir & symlink deps, Was: [CVS] RPM: rpm/ CHANGES rpm/lib/ rpmts.c
2010/12/14 Jeff Johnson :
>
> On Dec 14, 2010, at 3:00 PM, Per Øyvind Karlsen wrote:
>
>>
>> On a related note though I've started giving parentdir & symlink deps
>> some more thoughts again though, skimming the surface on practical
>> issues and drawbacks of such as ie. the size of files.xml.lzma in
>> main/release currently being 3736704 bytes compared to the gzip
>> compressed synthesis.hdlist.cz being as small as 775230 bytes (if
>> switching to xz compression, size could be trimmed down ~30%
>> further), so something more optimal than requiring this metadata which
>> currently for a single repository alone is bigger in size than the sum
>> of synthesis for all repos together. The necessary cleaning implied by
>> stricter policies on ownership and getting rid of all the incorrectly
>> multiple owned directories might improve it marginally, putting some
>> thinking into the format of the metadata (with something as repetetive
>> data as lists of paths are, I bet there must be some room for improval
>> utilizing this knowledge about the data to compress) might improve
>> things a bit as well, but deltas are the only known solution to
>> worthwile size reduction gains to at least reducing the pain of having
>> to download large metadata files with minimal changes between
>> frequently when being on a rolling distro such as ie. cooker, although
>> putting maintenance headaches of maintaining several deltas for it to
>> work (bundling several deltas into some indexed revision history to
>> match against older revisions of the metadata could perhaps be an idea
>> to make things slightly less messy perhaps?).
>>
>
> The issues of the size of files.xml* and synthesis.hdlist* have nothing
> whatsoever to do with parentdir/linkto dependencies.
But for being able to resolve these dependencies, one still needs the
metadata of files.xml, which synthesis.hdlist lacks..?
>
> The Mandriva flaw (imho) was adding
> Provides: /path/to/file
> so that file dependencies end-up in (the equiv of) primary.xml*
> and files.xml* doesn't need to be downloaded. Well you can do that,
> but "cherry picking" dependencies that you think you need and putting
> a representation in a different file, addresses only the bandwiidth
> savings (by avoiding need for files.xml* download) without really
> addressing the fundamental problem of dependency data reduction.
Yeah, which is why we generally have a policy against file dependencies
and explicit /path/ provides for a few files added to a handful of packages..
(In the past the tools used to generate synthesis automatically added
provides for file dependencies, but that required for all medias to
generate synthesis for to be be generated at the same time, breaking
any independently generated synthesis which wouldn't get analyzed for
the required file dependencies to add provides for etc.)
>
> Deltas (and compression) aren't the only means to data reduction.
> There is --rsyncable (and a change in transport) and there is
Yes, but not available for xz quite yet..
> also "binary xml" used to some extent in Apple *.plist and there's
> a similar binary representation (with associated data reduction) of
> XML here:
> http://www.ccnx.org/releases/latest/doc/technical/BinaryEncoding.html
> The point is that there's more solutions than deltafication/compression
> available.
Interesting, will read up on :)
>
> There's also nothing wrong with a "less == more" approach to bandwidth
> reduction:
> release repository metadata monthly or weekly rather than daily or hourly.
>
> This will cause some pain for developers, but those are exactly the
> people likelier to have bandwidth and be interested in timeliness.
Currently living with my mom in an area with not the best 3G coverage,
I'm deeply offended by such an assumption. ;p
>
> Most users (who drive the RFE for bandwidth/data reduction ultimately) would
> benefit from _NOT_ having to download all the "stuff" repeatedly.
>
> A properly engineered solution needs to be incremental (perhaps
> that's what you meant instead of delta?),
yupp :)
> distributing metadata
> only for the changed packages, not for everything all over again again.
>
> But overall, I would not expect parentdir/linkto dependencies to affect
> repository metadata size directly very much at all.
3.6Mmain/release/media_info/files.xml.lzma
7.6Mcontrib/release/media_info/files.xml.lzma
84K non-free/release/media_info/files.xml.lzma
[peroyv...@n4 media]$ du
{main,contrib,non-free}/release/media_info/synthesis.hdlist.cz
764Kmain/release/media_info/synthesis.hdlist.cz
1.4Mcontrib/release/media_info/sy
Re: Metadata size constraints wrt. parentdir & symlink deps, Was: [CVS] RPM: rpm/ CHANGES rpm/lib/ rpmts.c
2010/12/14 Jeff Johnson :
>
> On Dec 14, 2010, at 4:49 PM, Per Øyvind Karlsen wrote:
>
>>>
>>> The issues of the size of files.xml* and synthesis.hdlist* have nothing
>>> whatsoever to do with parentdir/linkto dependencies.
>> But for being able to resolve these dependencies, one still needs the
>> metadata of files.xml, which synthesis.hdlist lacks..?
>
> Well parentdir/linkto dependencies require zero bytes of
> storage because they are synthesized relations from
> other metadata implied by {DIRNAMES,BASENAMES,DIRINDEXES}
> and FILELINKTOS, not the usual dependency {N,EVR,F} triple.
I know, and therefore the dependency solver needs to know about what
files comes with the packages it's gonna install to know about the
parent directory dependencies of those and which packages that
provides those, right?
>
> But if you wanted to represent, say, parentdir dependencies
> explicitly in order to estimate the bandwidth/download cost,
> one just has to look at the Dirnames <-> Filepaths stores
> in /var/lib/rpm:
Won't have much luck finding much there for packages not yet installed, with
parent directories not yet installed by any packages on system either,
will I? ;)
>
> $ ls -al Dirnames Filepaths
> -rw-r--r--. 1 root root 1556480 Dec 13 18:41 Dirnames
> -rw-r--r--. 1 root root 22540288 Dec 13 18:41 Filepaths
>
> So markup for parentdir dependencies will take about
>
> 1.6 / 22.5 * 100 = 7.1%
>
> of the storage that files.xml* takes (yes files.xml is mostly a
> super-set of directories modulo issues like unowned and multiply
> owned directores: I am just estimating here).
But how can the dependency solver deal with parent directory dependencies
and based on it without having this information available to it?
>
> There are some very simple data reductions on hierarchical
> paths too. One of the best known is
> Run a dictionary: assign an integer weighted by # of
> occurences to favor small integers for frequently
> encountered tokens between /.../ (all of "usr" and "bin"
> and "lib" and "var" will have small integers assigned).
>
> This was used by *BSD find/locate to reduce the size needed
> for all possible paths to something much smaller that could be
> read/regenerated easily (KEY:VAL dictionary up front, integer
> substituted strings with lookup for single pass regenerate).
>
> Somebody Woods devised the *BSD path locate encoding in 1984 iirc.
>
> see whatever linux is doing (likely not too much/better) with
> find/locate for data reduction and speed-ups.
>
> I's expect (from actual experience on PDP/VAX ;-) at least another
> order of magnitude reduction in data size _BEFORE_ compression.
Yeah, just kinda what I'm looking for. :)
>
> So the universe of parentdir Provides: likely fits in
> 7.1 / 10 ~= 1%
> of the size of the existing files.xml store.
I'm still not sure if I follow you here, are you speaking of an
alternative to files.xml (if so, then we're on the same page), or are
you saying there being no need for this data available in external
metadata?
>
> None of the above is rocket science, just exploiting redundancy
> redundancy in /bing/bang/boom paths with specific fore knowledge,
> rather than relying on Huffman encoded dictionaries with adaptive
> statistics.
Yeah, that was kinda what I was thinking in terms of repetitive data
with well knowledge of. :)
>
> The point is that there's nothing very useful or sane about files.xml*
> as currently (and naively) encoded in XML. Just a teensy amount
> of thought saves far more bandwidth than any amount of spewage/formatting
> discussion.
Yupp, while I was able to reduce the size of files.xml.lzma by 25% by
tuning compression options for text compression (--text preset option
for this set of options have been added and in use for man & info page
compression ever since we first switched to lzma, for those interested
patch is available at:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/xz/releases/5.0.0/2mdv2011.0/SOURCES/xz-5.0.0-text-tune.patch?view=markup
, 'xz -0 --text' is fit specifically for smaller files and what's
being used for man & info pages, higher levels will (only) increase
dictionary size), current xml format not being suitable was already
taken for granted, there's also the shortcoming of it simply being a
list of paths without the required information about those. One could
always simply add a '/' at end of path of directories to identify them
as such, but slipping in information about symlinks couldn't be done
as discreetly...
Thx for pointers with hints on alternatives, I'll look into those. :)
>
> Disclaimers:
>
Re: Metadata size constraints wrt. parentdir & symlink deps, Was: [CVS] RPM: rpm/ CHANGES rpm/lib/ rpmts.c
2010/12/15 Jeff Johnson :
>
> On Dec 14, 2010, at 9:51 PM, Jeff Johnson wrote:
>
>>
>> Download. uncompress. use for file dependencies.
>>
>> I will take wagers on how much smaller the encoding is as
>> soon as you tell me what you choose for {n,p}.
>>
>
> There's an obvious generalization here for primary.xml
> data as well as for all version-less dependencies like
> Requires: libc.so.6
> and all the variants (see rpm -q --provides glibc spewage).
>
> All of that crap can be collapsed into a single per-package Bloom filter
> that also includes not only all paths contained within a package,
> but also all version-less Provides.
I just played around with rpmbf a bit and tried making a bloom filter
of all the files in a hdlist, and I wonder if I might've gotten things
wrong, size I end up with of the dump is pretty much around the same
as for when compressing the files.xml.lzma:
[peroyv...@lappis samples]$ ./hdlist-bf hdlist-main
n: 1021318 m: 29368178 k: 19
size: 3671022
So I guess there's something I'm not really fully grasping here...
See code attached...
--
Regards,
Per Øvind
#define _RPMGI_INTERNAL
#define _RPMBF_INTERNAL
/* avoid warning */
#define xrealloc(ptr, size) realloc(ptr, size)
#include
#include
#include
#include
#include
int main(int argc, char *argv[]) {
FD_t fd;
rpmts ts = NULL;
rpmgi gi = NULL;
rpmRC rc = RPMRC_NOTFOUND;
rpmbf bf = NULL;
size_t n = 0;
static double e = 1.0e-6;
size_t m = 0;
size_t k = 0;
HE_t he = (HE_t)memset(alloca(sizeof(*he)), 0, sizeof(*he));
rc = RPMRC_NOTFOUND;
ts = rpmtsCreate();
rpmtsSetRootDir(ts, NULL);
gi = rpmgiNew(ts, RPMDBI_HDLIST, NULL, 0);
rpmtsSetVSFlags(ts, _RPMVSF_NOSIGNATURES | RPMVSF_NOHDRCHK | _RPMVSF_NOPAYLOAD | _RPMVSF_NOHEADER);
gi->active = 1;
gi->fd = Fopen(argv[1], "r.fdio");
while ((rc = rpmgiNext(gi)) == RPMRC_OK) {
int rc;
he->tag = RPMTAG_FILEPATHS;
if(headerGet(gi->h, he, 0)) {
n += he->c;
}
}
rpmbfParams(n, e, &m, &k);
bf = rpmbfNew(m, k, 0);
gi->active = 1;
gi->fd = Fopen(argv[1], "r.fdio");
while ((rc = rpmgiNext(gi)) == RPMRC_OK) {
int rc;
he->tag = RPMTAG_FILEPATHS;
if(headerGet(gi->h, he, 0)) {
for(he->ix = 0; he->ix < (int) he->c; he->ix++)
rpmbfAdd(bf, he->p.argv[he->ix], 0);
}
}
fd = Fopen("bloom.dump", "w.fdio");
Fwrite(bf->bits, 1, bf->m/8, fd);
Fclose(fd);
printf("n: %zu m: %zu k: %zu\nsize: %zu\n", n, m, k, bf->m/8);
}
Re: Metadata size constraints wrt. parentdir & symlink deps, Was: [CVS] RPM: rpm/ CHANGES rpm/lib/ rpmts.c
2010/12/18 Jeff Johnson : > > On Dec 17, 2010, at 2:22 PM, Jeff Johnson wrote: > >> >> On Dec 17, 2010, at 1:48 PM, Per Øyvind Karlsen wrote: >> >>> >>> So I guess there's something I'm not really fully grasping here... >>> >>> See code attached... >>> >> >> Yes. You miss that you need to estimate the expected size of the >> population you wish to capture in a Bloom Filter: >> >> size_t n = 0; /* <-- 0 will end up using an inappropriate default */ >> >> rpmbfParams(n, e, &m, &k); >> > > The default is 1 (for no purpose other than a default was needed). > >> WHat you need to do (if you wish to base your estimate on the "real world") >> is something like this >> >> rpm -qal | sort -u | wc -l >> and then add 10% (which won't really matter but will make you feel better). >> > > And I missed the double loop ... you actually are/were estimating n. > Apologies for missing reading the code. > >> You likely also can get away with >> static double e = 1.0e-4; >> because (if you happen to hit a false positive in perl-URPM) its >> not the end-of-the-world, just means that you will download >> a package unnecessarily and add to transaction which will >> be caught by rpmtsCheck() later. So "one-in-a-million" or >> "one-in-a-billion" a priori estimates of an acceptable >> probability for a false positive need to also look at >> what happens with a "false positive" failure. >> > > Using 10**-4 instead of 10**-6 will reduce the bit maps a fair amount. k, that reduced it to 2,4M > >> Also try adding >> _rpmbf_debug = -1; >> while getting up to speed on the parameter choices. >> >> See also tdict.c test case in POPT using /usr/share/dict/words >> that you ought to look at. It literally doesn't matter whether words >> or filepaths are uses for set memember tokens, hashing chooses some >> set of bits to flip to track set membership. The actual tokens used >> don't matter a bit. >> >> Your code is likely gonna need a per-package Bloom filter with NEVRA >> identifier, >> because what perl-URPM need first is a list of what packages to download. As >> written, you collapsing all paths in a repository into a single Bloom >> filter. You need an array of per-package Bloom filters. >> >> If you choose all per-package Bloom filters to be the same size (estimator >> is ~10% larger than the size of the filelist in the package with the >> most files, which should be something like 30-40K and with a probability >> of false positive of ~0.01% (1.0e-4)), then you can use >> rpmbfUnion/rpmbfIntersect >> exactly the same as one would use OR and AND operations for boolean >> TRUE/FALSE. >> > > Switching to per-package Bloom-filters with an estimated population of ~50K > will increase the aggregate size of the array of bit maps because most > packages > don't have anywhere near 50K paths ... > > .. but when you write the array, open with "w.xzdio" so that you are comparing > compressed against compressed sizes. The sparse bit maps will compress > extremely well. > > You are already seeing that a *uncompressed* Bloom filter using conservative > parameters like 10**-6 is comparable in size to the traditional *compressed* > file paths. With 10**-4, and a per-package population estimate of ~50K, > and compression on the array of Bloom filters, I expect you will start > to see a major reduction in the size of the file that needs to be transported, > with the additional advantage that the data will be pre-encoded in a form > that is high-performing and efficient, unlike lots of strcmp's, which would > need marshalling into a dict etc etc. Well, for my simple test case, the bloom filter were fully populated and any attempts at compression only added the overhead of the header to the compression size.. > > You will have to fuss about endianness, and what hash is being used, for > portability. The Jenkins lookup3 hash is already tuned w loop-unrolling etc, > and its properties are well known. > >> So one can attempt a fancier bsearch "bisection" with better performance >> down the road instead of a linear search to find which package contains >> a given file path by looping over per-package Bloom Filters with identifiers >> like NEVRA or URI. There's likely other performance wins that can be devised >> since packages with a given prefix are likely to be the same end-point for >> an unknown file path that is a continuation of the given prefix. >> > > The "bisection" likely isn't worth worrying about until there is need. But > rpmbdUnion/rpmbfIntersect are useful operations on arrays of fixed size > Bloom filters no matter what. I'll need to read up on this closer later, I'm on my way out, will get back to ya. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/lib/ rpmts.h rpm/rpmdb/ rpmns.h rpmtypes.h rpm/rpmio/ r...
2010/12/21 Jeff Johnson : > Id there a compilation faulure here? Or just C fetishism? ;-) > > If there's a compilation failure, I'll adjust my own coding practices > (aka fetishism ;-) accordingly. Only with -pedantic -Werror.. ;) Just stumbled across it when enabling most warning flags (ie. such as -Weffc++, -Wold-style-cast etc.) I prefer to have enabled when working on c++ libraries, as I played around with libdudf and I felt unhappy when seeing so much C being done in C++.. ;p -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/lib/ rpmts.h rpm/rpmdb/ rpmns.h rpmtypes.h rpm/rpmio/ r...
2010/12/21 Jeff Johnson : > > On Dec 21, 2010, at 7:27 AM, Per Øyvind Karlsen wrote: > >> 2010/12/21 Jeff Johnson : >>> Id there a compilation faulure here? Or just C fetishism? ;-) >>> >>> If there's a compilation failure, I'll adjust my own coding practices >>> (aka fetishism ;-) accordingly. >> Only with -pedantic -Werror.. ;) >> > > Ah k, I tend to avoid -pedantic (too nit-picky, I have to use the compiler > I have, not the compiler I want), and -Werror is Just Too Much Pain (I > want to see all the issue, not come FULLSTOP on the next issue). > >> Just stumbled across it when enabling most warning flags (ie. such as >> -Weffc++, -Wold-style-cast etc.) I prefer to have enabled when >> working on c++ libraries, as I played around with libdudf and I felt >> unhappy when seeing so much C being done in C++.. ;p >> > > What plans for -ldudf? The current mixture of JSON -> XML for an rpmdb > is kinda qwazy. Sure you can do a full database dump into XML CDATA but ... > why? To be honest, no idea, I just initially went ahead and did the rpm5 porting as we had a package of libdudf in cooker, then Stéphane gave me a pointer to the the master branch and commit access and I went on just giving it some extra care in the process of commiting my changes with some additional improvements... IIRC the others seemed to prefer to have things done in rpm if the alternative were given, I briefly looked at the code of libdudf wrt. urpmi and was thinking about perhaps merging it and introduce more proper support already.. So if you have a better solution and can provide it through rpm, I guess everyone would be more happy going through that route in stead and I'll probably be able to adopt it in urpmi sooner as well.. :) On these things, my oppinions and insight are rather limited beyond doing some work on the stuff I know and can improve upon related to it (in this case use and knowledge of librpm API and good C++&STL knowledge, pretty much it for now), no time to dig too much below the surface.. So any better suggestions, advice, and other alternatives handed to me are more than welcome, you're certainly the expert on these things, not me. :) -- Regards, Per Øyvind -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
RFC: pythonembed dlopen()
To make it possible to consider enabling embedding of interpreters, I'd say it's crucial to not tie them in as dependencies to break rpm completely if missing (ie. perl changing path to libperl.so for each micro release) or pulling in large dependencies or anything... Here's a patch that adds dlopen() support for python embedding, autofoo stuff already broken for both perlembed & pythonembed already, trying to fix it and avoiding linking when doing dlopen() gave me headaches and for to figure out later.. WDYT? -- Regards. Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: RFC: pythonembed dlopen()
2010/12/23 Jeff Johnson :
>
> On Dec 23, 2010, at 4:24 PM, Per Øyvind Karlsen wrote:
>
>> To make it possible to consider enabling embedding of interpreters,
>> I'd say it's crucial to not tie them in as dependencies to break rpm
>> completely
>> if missing (ie. perl changing path to libperl.so for each micro
>> release) or pulling
>> in large dependencies or anything...
>>
>> Here's a patch that adds dlopen() support for python embedding, autofoo stuff
>> already broken for both perlembed & pythonembed already, trying to fix it and
>> avoiding linking when doing dlopen() gave me headaches and for to
>> figure out later..
>>
>
> No patch, but I can guess ...
though, here goes.. ;)
I think the behaviour when no python can be loaded isn't the entirely
appropriate, also 'rpmlib(BuiltinPythonScripts)' should probably
rather be determined at run time as well...
>
> Let's deal with perl for an example, largely because
> an embedded perl interpreter can be instantiated
> multiple times, with multiple identical loads,
> which is (perhaps) more general than other widdle
> interpreters like python and ruby.
>
> When rpmperlNew is called, this script is fed to the interpreter:
>
> static const char * rpmperlInitStringIO = "\
> use strict;\n\
> use IO::String;\n\
> our $io = IO::String->new;\n\
> select $io;\n\
> ";
>
> This -- of course -- breaks almost always becuse
> the IO::String module isn't Artistic enuf any more.
>
> When the IO::String module isn't present, then
> the necessary mapping of stdout to a buffer doesn't happen.
>
> Without buffer content, all %{perl OPTS ARGS: BODY} macro expansions
> break.
>
> Whether IO:String a "hard" or "soft" or "I'm an Artist!" dependency
> I'l leave to the bikeshed. But there's certainly ways within perl
> to detect a failed module load, and print out errors, and try fallbacks
> without writing dlopen() directly.
>
> Module loading using dlopen(3) is built into perl, I see no reason to try to
> out-guess the Artists in C code in RPM.
Well, currently to get it building I have to pass include path to
CPPFLAGS & library path + rpath to LDFLAGS.
With libperl.so for me being located in
/usr/lib/perl5/5.12.2/x86_64-linux-thread-multi/CORE/libperl.so, this
obviously blows...
>
> But the startup script needs to be moved into a template, very not hard
> mechanically, but how that perl interpreter initialization WILL need
> some serious thought from some perl Artist willing to think through
> perl embedding, and to suggest something reasonable.
>
> All I've done is the bare minimum necessary to get perl embedded,
> sketching in structural elements that WILL be needed for "real world"
> usage. E.g. I could have quite easily hard-wired a stdout file descriptor
> into a buffer using C code; I chose IO::String instead.
>
> Make sense?
Not sure if I get things properly, haven't looked into rpmio/rpmperl.c
much at all, but it does at least link against libperl.so, intended or
not..?
>
> Meanwhile I'm really really hoping to be able to piggy back dlopen(3)
> using already implemented functionality in one of these widdle interpreters,
> rather than have to go through the tedium of Yet Another dlopen(3) Wrapping.
>
> But without some clear interest in SOME embedding (JavaScript was the chosen
> embedding, lua is the historical embedding, the other embeddings are there
> largely
> to pre-empt vacuous discussions about the relative merits of the widdle
> interpreters:
>
> You like ? Here it is, implemented in RPM, go
> figger and use!
I'm all ready to enable these, just trying to avoid pulling in a lot
of dependencies and features without anyone really using them..
We'll get there eventually... :)
--
Regards,
Per Øyvind
--- rpmio/rpmpython.c 2010-11-21 06:09:34.728809000 +0100
+++ /home/peroyvind/RPM/rpm5/BUILD/rpm-5.3.7/rpmio/rpmpython.c 2010-12-23 22:12:50.106785798 +0100
@@ -10,6 +10,66 @@
#if defined(WITH_PYTHONEMBED)
#include
#include
+
+#if defined(HAVE_DLFCN_H)
+#include
+#include
+
+extern PyAPI_FUNC(void) Py_SetProgramName(char *);
+static PyAPI_FUNC(void) (*Py_SetProgramName_p) (char *);
+extern PyAPI_FUNC(void) Py_Initialize(void);
+static PyAPI_FUNC(void) (*Py_Initialize_p) (void);
+extern PyAPI_FUNC(void) Py_Finalize(void);
+static PyAPI_FUNC(void) (*Py_Finalize_p) (void);
+extern PyAPI_FUNC(int) Py_IsInitialized(void);
+static PyAPI_FUNC(int) (*Py_IsInitialized_p) (void);
+
+extern PyAPI_FUNC(PyObject *) PyRun_StringFlags(const char *, int, PyObject *,
+ PyObject *, PyCompilerF
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ rpmrc.c rpm/rpmio/ librpmio.vers look...
2010/12/25 Jeff Johnson : > Ick. > > WITH_VALGRIND is a compile, not a run-time, option, Which was semi-broken due to mixup between usage of #ifdef WITH_VALGRIND & #ifdef VALGRIND and also a missing ';'.. :p I haven't changed it being a compile option though, only the means to detect whether actually running under valgrind when compiled with WITH_VALGRIND, this so that the jlu32*() functions will run the faster code when not running under valgrind, while running the valgrind friendly code only when running under valgrind. This is quite sensible behaviour IMO at least. :) > > And I haven't a clue why there's a change needed > for lib/rpmc.c. Presumably its for --showrc ... > ... do you really think anyone cares? No, it's for detecting whether running under valgrind, I figured this possibly being the most appropriate place to do so to detect as early as possible if of use as early as possible, doing it one time only. > > And there's already a means to just set a macro, > where the display with --showrc Just Happens. Not trying to set a macro nor messing with --showrc display. > > And WITH_VALGRIND turns on memory pool annotations > without which valgrind is useless. I'm not touching this at all. ;) > > I'd say just don't obsess like this. > > Or go create 100+ external libraries, with and without > valgrind options, so the entire world, not just RPM, benefits > from squeaky clean valgrind spewage. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/lib/ transaction.c
2010/12/26 Jeff Johnson : > Ick (but I've had to do worse when necessary). > > If you can give me a toy package reproducer, I can likely > help get something better in place. > > I'd guess (since all of these are %doc files afaict) > that the precedence order of %doc handling and file > conflicts is what is tripping you up. > > But I can't do file conflict resolution in my head ... See post related to earlier file conflict issue from a few mins ago.. ;) For toy package reproducers, you can try gnupg & gnupg2 from cooker. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/lib/ transaction.c
2010/12/26 Jeff Johnson : > > On Dec 26, 2010, at 4:52 PM, Per Øyvind Karlsen wrote: > >> >> For toy package reproducers, you can try gnupg & gnupg2 from cooker. >> > > Those aren't toys. What's needed is simple reproducers. Here's btw. a report opened on the issue this commit fixes: (unfortunately the conflicting files issue discusssed in the separated thread is preventing it from solving it though) https://qa.mandriva.com/show_bug.cgi?id=61997 -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/lib/ transaction.c
2010/12/27 Jeff Johnson : > > On Dec 26, 2010, at 7:39 PM, Per Øyvind Karlsen wrote: > >> 2010/12/26 Jeff Johnson : >>> >>> On Dec 26, 2010, at 4:52 PM, Per Øyvind Karlsen wrote: >>> >>>> >>>> For toy package reproducers, you can try gnupg & gnupg2 from cooker. >>>> >>> >>> Those aren't toys. What's needed is simple reproducers. >> Here's btw. a report opened on the issue this commit fixes: >> (unfortunately the conflicting files issue discusssed in the separated >> thread is preventing it from solving it though) >> https://qa.mandriva.com/show_bug.cgi?id=61997 > > Thanks for the bug report pointer. > > Note that man pages are involved, also in one of the other > reports are sent. man pages are silently marked as documentation, > which causes a different path through the file state code. > > Ah yes, some of the details start to come back to me ... > > ... you end up seeing file conflicts on identical paths and > even with identical content because of a time stamp embedded > in *.gz (no clue *.xz or *.bz2, but likely the same). > > The "fix" way back when was to ensure "gzip -n" (to turn off the > time stamp, check the gzip man page). > > Are all these file conflicts with compressed man pages? These conflicts are all related to any files found under those paths, independent of compression or not. The original motivation was related to coloring, whereas we treat non-identical files of different color as conflicts, while not caring to be as strict for doc conflicts between packages wrt. multilib -devel packages etc.. Looking at the resulting conflicts I've run into, these have all been different kind of conflicts not related to what originally aimed at (between multilib -devel packages), so this patch should probably be made stricter and only apply to files of different coloring built from same source package... WDYT? I need to take a closer look at the files conflicting, but I suspect most of the conflicting files might be non-identical, thus considered packaging mistakes to be fixed, currently masked by this patch... -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/lib/ transaction.c
2010/12/28 Jeff Johnson : > I think the intent is savable and useful even if the > hardwired paths is hacky. Yeah, but I reached the conclusion that the actual need wasn't really there, the only conflicting man pages between multilib packages I stumbled across was one reaching a small window where someone had changed xz compression options (due to the person updating xz to 5.0.0 dropping the --text patch without me noticing) before I fixed back again, thus a man page compressed with 'xz -9' & 'xz -0 --text' between i586 & x86_64 ended up conflicting. So as these -devel packages usually shouldn't have file conflicts between them (whereas they do, it's usually due to bugs needing to be fixed in them), I don't think this hack ultimately achieves anything beyond masking packaging errors. And for policies, yes, we do actually have those in place already to always add explicit conflicts already where appropriate rather than relying on (uncertainly intended) file conflicts (espcially since we do not have the required information in the synthesis metadata).. > > See how _dependency_whiteout (or the PLD filtering if you > want to chase patterns) is wired up with a macro, > and do the same thing with your ignorelist. yeah, I've glanced at it with some curiousity already (not gotten to put much thought and understanding in yet though), but with a different motivation, namely ordering issues with ie. 'urpmi --root blabla basesystem' into a new chroot giving trouble with scriptlets.. Not sure if it's related, yet to really look into... > > What needs doing going "forward" in RPM is attempting to unify > multilib/%config/replaced/coloring and more rule based "policy" > for determining file state resolutions while installing. Indeed.. (Sorry for being a bit slow in responding and in responses themself lately btw., my head and mind has been clogged up by muckus and I've been coughing up my lungs for the past week.) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: What to do about RPM file conflicts?
2010/12/28 Jeff Johnson : > I'd tend to agree: packaging error. But that isn't my call ... For Mandriva, certainly packaging errors. :) > There are like 10 "replaced" files (out of 300K -> 1M files in a modern distro > like Mandriva) that actually have the state "replaced". All of the paths > reported are/were due to man-page compression afaict (all paths were > /usr/share/ma/...) Nah, none of those were, I only encountered one such incident myself, which was due to change of compression settings used between multilib -devel packages. For the paths reported, those were rather pure packaging errors with files having different content (across completely different packages, not multilib related), conflicts masked by the patch (and the reason for backing it out). I've started cleaning out most of these packaging mistakes already. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Using Fopen() [Was: Re: error: ‘struct FDIO_s ’ has no member named ‘_open’]
2010/12/29 Silvan Calarco : > Hi, > > On Tuesday 28 December 2010 17:01:50 Jeff Johnson wrote: >> The solution here is to use Fopen(), not fdOpen(). > > I'm testing this in a function but it doesn't work: > > FD_t fd; > int rc; > > fd = Fopen(headerFile, O_RDONLY); try: fd = Fopen(headerFile, "r"); ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ rpmrc.c rpm/rpmio/ librpmio.vers look...
2010/12/29 Jeff Johnson : > RPM Package Manager, CVS Repository > http://rpm5.org/cvs/ > > > Server: rpm5.org Name: Jeff Johnson > Root: /v/rpm/cvs Email: ...@rpm5.org > Module: rpm Date: 29-Dec-2010 17:33:54 > Branch: HEAD Handle: 2010122916335201 > > Modified files: > rpm CHANGES > rpm/lib rpmrc.c > rpm/rpmio librpmio.vers lookup3.c > > Log: > - revert lookup3.c+valgrind because gcc version dependent. Uhm, not really, although I forgot to commit changes to debug.h which have a conditional gcc specific optimization (see below). You also reverted a fix for the broken #ifdef VALGRIND vs #ifdef WITH_VALGRIND btw. --- debug.h 2010-01-17 13:16:30.0 +0100 +++ /home/peroyvind/RPM/rpm5/BUILD/rpm-5.3.7/debug.h2010-12-25 21:10:45.763314086 +0100 @@ -28,6 +28,15 @@ #include #include +/* If we're using GCC, use __builtin_expect() to reduce overhead of + the valgrind checks */ +#if defined(__GNUC__) && (__GNUC__ > 2) && defined(__OPTIMIZE__) +# define UNLIKELY(value) __builtin_expect((value), 0) +#else +# define UNLIKELY(value) (value) +#endif + +extern int _running_on_valgrind; #else #defineVALGRIND_CREATE_MEMPOOL(pool, rzB, is_zeroed) __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ rpmrc.c rpm/rpmio/ librpmio.vers look...
2010/12/29 Jeff Johnson : > So fix it. I need to build on HEAD. Yeah, I'd imagine.. ;) Sorry, didn't notice that I forgot debug.h before I saw it missing from the revert, will fix! I guess the missing debug.h changes might've caused some of the confusion about the commit earlier. > > Note that __builtin_expect is GCC peculier and > equally non portable. yeah, hence the "conditional" and portable alternate macro. ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ configure.ac devtool.conf
2011/1/9 Jeff Johnson :
> Dare I ask?
>
> WTF arre "pre-macros"?
>
> If they are what I think they are (i.e same as --predefine),
> it ain't gonna work.
>
> Been there, done that.
Used to define macros before loading all the rest, this to be able
to set default %_target_cpu with libcpuinfo by using
%_prefer_target_cpu (see lib/rpmrc.c) so that it's known before
loading arch specific macros, otherwise %_host_cpu == %_target_cpu
(ie. 'pentium4' on x86_64 with 32 bit personality set) when loading
/usr/lib/rpm/platform/%{_target}/macros.
[peroyv...@lappis ~]$ cat /etc/rpm/premacros.d/cpuinfo_target.macros
# This sets which of the available architectures to prefer when building
# packages with libcpuinfo support enabled.
%_prefer_target_cpu x86_64 i586
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
ordering issues
I've run into some ordering issues installing into a fresh chroot: installing findutils-4.5.9-1mdv2011.0.i586.rpm nss_tcb-1.0.6-0mdv2011.0.i586.rpm cracklib-dicts-2.8.16-2mdv2011.0.i586.rpm perl-base-5.12.2-5mdv2011.0.i586.rpm setup-2.7.18-2mdv2011.0.i586.rpm shadow-utils-4.1.4.2-8mdv2011.0.i586.rpm perl-5.12.2-5mdv2011.0.i586.rpm libtcb0-1.0.6-0mdv2011.0.i586.rpm coreutils-8.9-1mdv2011.0.i586.rpm tcb-1.0.6-0mdv2011.0.i586.rpm rpm-helper-0.23.1-2mdv2011.0.noarch.rpm pam-1.1.3-1mdv2011.0.i586.rpm pam_tcb-1.0.6-0mdv2011.0.i586.rpm libacl1-2.2.49-4mdv2011.0.i586.rpm from /mnt/BIG/dis/cooker/i586/media/main/release starting installing packages created transaction for installing on /export/home/mandrake//chroot_tmp/peroyvind/chroot_cooker.0.20110112202034.tmp.NlZKPz (remove=0, install=0, upgrade=14) Preparing... 33/599: setup 34/599: libacl1 35/599: cracklib-dicts 36/599: findutils 37/599: libtcb0 38/599: pam_tcb 39/599: perl-base 40/599: perl 41/599: rpm-helper 42/599: nss_tcb 43/599: pam /var/tmp/rpm-tmp.29348: line 2: install: command not found grep: /etc/login.defs: No such file or directory /var/tmp/rpm-tmp.29348: line 5: /usr/sbin/set_tcb: No such file or directory error: %post(pam-1.1.3-1mdv2011.0.i586) scriptlet failed, exit status 127 44/599: shadow-utils 45/599: coreutils 46/599: tcb pam has the following relevant dependencies: pam has the following dependencies: Requires: cracklib-dicts Requires: setup >= 2.7.12-2 Requires: pam_tcb >= 1.0.2-16 Conflicts: initscripts < 3.94 Requires(pre): rpm-helper Requires(post): coreutils Requires(post): tcb >= 1.0.2-16 coreutils has these: Requires: pam >= 0.66-12 So there's a dependency loop here that with rpm 4.6 seems to have been solved by Requires(post), but the behaviour is different with rpm 5.3. Is this a packaging bug, or rpm bug? I'm not sure about what's considered as correct behaviour or not on this one.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: ordering issues
2011/1/12 Per Øyvind Karlsen : > I've run into some ordering issues installing into a fresh chroot: > > installing findutils-4.5.9-1mdv2011.0.i586.rpm > nss_tcb-1.0.6-0mdv2011.0.i586.rpm > cracklib-dicts-2.8.16-2mdv2011.0.i586.rpm > perl-base-5.12.2-5mdv2011.0.i586.rpm setup-2.7.18-2mdv2011.0.i586.rpm > shadow-utils-4.1.4.2-8mdv2011.0.i586.rpm > perl-5.12.2-5mdv2011.0.i586.rpm libtcb0-1.0.6-0mdv2011.0.i586.rpm > coreutils-8.9-1mdv2011.0.i586.rpm tcb-1.0.6-0mdv2011.0.i586.rpm > rpm-helper-0.23.1-2mdv2011.0.noarch.rpm pam-1.1.3-1mdv2011.0.i586.rpm > pam_tcb-1.0.6-0mdv2011.0.i586.rpm libacl1-2.2.49-4mdv2011.0.i586.rpm > from /mnt/BIG/dis/cooker/i586/media/main/release > starting installing packages > created transaction for installing on > /export/home/mandrake//chroot_tmp/peroyvind/chroot_cooker.0.20110112202034.tmp.NlZKPz > (remove=0, install=0, upgrade=14) > Preparing... > > 33/599: setup > > 34/599: libacl1 > > 35/599: cracklib-dicts > > 36/599: findutils > > 37/599: libtcb0 > > 38/599: pam_tcb > > 39/599: perl-base > > 40/599: perl > > 41/599: rpm-helper > > 42/599: nss_tcb > > 43/599: pam > > /var/tmp/rpm-tmp.29348: line 2: install: command not found > grep: /etc/login.defs: No such file or directory > /var/tmp/rpm-tmp.29348: line 5: /usr/sbin/set_tcb: No such file or directory > error: %post(pam-1.1.3-1mdv2011.0.i586) scriptlet failed, exit status 127 > 44/599: shadow-utils > > 45/599: coreutils > > 46/599: tcb > > > pam has the following relevant dependencies: > pam has the following dependencies: > Requires: cracklib-dicts > Requires: setup >= 2.7.12-2 > Requires: pam_tcb >= 1.0.2-16 > Conflicts: initscripts < 3.94 > Requires(pre): rpm-helper > Requires(post): coreutils > Requires(post): tcb >= 1.0.2-16 > > coreutils has these: > Requires: pam >= 0.66-12 > > So there's a dependency loop here that with rpm 4.6 seems to have > been solved by Requires(post), but the behaviour is different with rpm 5.3. Hm, even when removing the requires on pam for coreutils, the package ends up being installed at the
Re: ordering issues
2011/1/12 Per Øyvind Karlsen : > 2011/1/12 Per Øyvind Karlsen : >> I've run into some ordering issues installing into a fresh chroot: >> >> installing findutils-4.5.9-1mdv2011.0.i586.rpm >> nss_tcb-1.0.6-0mdv2011.0.i586.rpm >> cracklib-dicts-2.8.16-2mdv2011.0.i586.rpm >> perl-base-5.12.2-5mdv2011.0.i586.rpm setup-2.7.18-2mdv2011.0.i586.rpm >> shadow-utils-4.1.4.2-8mdv2011.0.i586.rpm >> perl-5.12.2-5mdv2011.0.i586.rpm libtcb0-1.0.6-0mdv2011.0.i586.rpm >> coreutils-8.9-1mdv2011.0.i586.rpm tcb-1.0.6-0mdv2011.0.i586.rpm >> rpm-helper-0.23.1-2mdv2011.0.noarch.rpm pam-1.1.3-1mdv2011.0.i586.rpm >> pam_tcb-1.0.6-0mdv2011.0.i586.rpm libacl1-2.2.49-4mdv2011.0.i586.rpm >> from /mnt/BIG/dis/cooker/i586/media/main/release >> starting installing packages >> created transaction for installing on >> /export/home/mandrake//chroot_tmp/peroyvind/chroot_cooker.0.20110112202034.tmp.NlZKPz >> (remove=0, install=0, upgrade=14) >> Preparing... >> >> 33/599: setup >> >> 34/599: libacl1 >> >> 35/599: cracklib-dicts >> >> 36/599: findutils >> >> 37/599: libtcb0 >> >> 38/599: pam_tcb >> >> 39/599: perl-base >> >> 40/599: perl >> >> 41/599: rpm-helper >> >> 42/599: nss_tcb >> >> 43/599: pam >> >> /var/tmp/rpm-tmp.29348: line 2: install: command not found >> grep: /etc/login.defs: No such file or directory >> /var/tmp/rpm-tmp.29348: line 5: /usr/sbin/set_tcb: No such file or directory >> error: %post(pam-1.1.3-1mdv2011.0.i586) scriptlet failed, exit status 127 >> 44/599: shadow-utils >> >> 45/599: coreutils >> >> 46/599: tcb >> >> >> pam has the following relevant dependencies: >> pam has the following dependencies: >> Requires: cracklib-dicts >> Requires: setup >= 2.7.12-2 >> Requires: pam_tcb >= 1.0.2-16 >> Conflicts: initscripts < 3.94 >> Requires(pre): rpm-helper >> Requires(post): coreutils >> Requires(post): tcb >= 1.0.2-16 >> >> coreutils has these: >> Requires: pam >= 0.66
Re: ordering issues
2011/1/13 Jeff Johnson : > > On Jan 13, 2011, at 4:24 AM, Per Øyvind Karlsen wrote: > >> >> So Id say that there's definitively something buggy going on with rpm here.. >> > > Try printing out the LOOP messages you've chosen to hide. > > Then fix your LOOP's. > > If claiming "something buggy going on with rpm here" makes you feel better, > have at! d'oh, k: error: LOOP: error: removing pam-1.1.3-1mdv2011.0.i586 "Requires(post): coreutils" from tsort relations. error: removing coreutils-8.9-1mdv2011.0.i586 "Requires: pam >= 0.66-12" from tsort relations. But given that Requires(post) indicates that it's required at scriptlet time, shouldn't rpm consider this as coretuils>pam? This seems to be the behaviour we've had and based our packaging on in cooker with rpm <= 4.6.. I'll be going through various other loops with %_depedendency_whitout now and try play my way through it.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: ordering issues
2011/1/13 Jeff Johnson : > > On Jan 13, 2011, at 5:29 AM, Per Øyvind Karlsen wrote: > >> >> But given that Requires(post) indicates that it's required at >> scriptlet time, shouldn't rpm consider this as coretuils>pam? >> > > There is no "scriptlet time". > > There are > 1) needed for installing > 2) required while installed > 3) needed for erasing > relations used for ordering. > > These relations split into 1+2 and 2+3 "times" (or sets) so its possible to > split a dependency loop with markers like Requires(post):. Yes, but Requires(post) suggests that something is required during %post, right? Shouldn't rpm then sort Requires(post): before Requires:? > > But the usage case is too narrow to be generally effective, and > its just as easy to arrange for the packaging to do the right ting. > >> This seems to be the behaviour we've had and based our packaging on in >> cooker with rpm <= 4.6.. >> > > (aside) > Claim anything you wish about rpm behavior: what's in rpm-5.3 has > hardly been changed in a decade. Its kinda ironic to hear the > noise about rpm broke this and broke that! Well, I dunno at which time it might've changed, but with rpm 4.6 Requires(pre,prein,post,postun): were sorted to be ordered before Requires:, which is something the packaging in cooker has been heavily relying on.. > >> I'll be going through various other loops with %_depedendency_whitout >> now and try play my way through it.. >> > > Adding %_dependency_whiteout is expedient: works and you will have a list > of what relations need to be fixed when you are done. > > I'd also start listing the LOOP's somehow. Invisible LOOP's will never > ever be fixed. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: ordering issues
2011/1/13 Jeff Johnson : > > On Jan 13, 2011, at 8:49 AM, Jeff Johnson wrote: > >>> Well, I dunno at which time it might've changed, but with rpm 4.6 >>> Requires(pre,prein,post,postun): were sorted to be ordered before >>> Requires:, which is something the packaging in cooker has been heavily >>> relying on.. >> > > If this is true, then point me at the code that sorts Requires(foo): before > Requires:. I wish I could point to the specific code, but wrapping my head around lib/order.c isn't that easy, otherwise I'd probably just jack the code in question and be done with it already rather than asking for help here.. ;) > > I have never seen any rpm patches that change package ordering as you have > stated. I'm gonna try give a new look at the code and also check if there's some mandriva specific patches I might've missed for this. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: ordering issues
2011/1/13 Jeff Johnson : > > On Jan 13, 2011, at 10:42 AM, Per Øyvind Karlsen wrote: > >>> >>>>>> >>>>> Well, I dunno at which time it might've changed, but with rpm 4.6 >>>>> Requires(pre,prein,post,postun): were sorted to be ordered before >>>>> Requires:, which is something the packaging in cooker has been heavily >>>>> relying on.. >>>> >>> >>> If this is true, then point me at the code that sorts Requires(foo): before >>> Requires:. >> I wish I could point to the specific code, but wrapping my head around >> lib/order.c isn't that easy, otherwise I'd probably just jack the code >> in question and be done with it already rather than asking for help >> here.. ;) > > Hint: What you suggested, that Requires(pre): etc are sorted before Requires:, > has never been implemented in RPM. Or show me the code and prove me wrong ;-) Well, I wish I could, here's the last rpm-4.6.1-5 package that was in cooker before the switch though: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/rpm/releases/1:4.6.1/5mnb2/ For it not being implemented, would it be a sane behaviour that's feasible to implement? -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/rpmdb/ db3.c
2011/1/18 Jeff Johnson : > Rip it out please. Or I will. > > One cvan set the log directory in DB_CONFIG. > > Using DB_CONFIG is the means to set parameteres configrurably > for Berkeley DB. If you find the Berekeley DB configuration > machainsim useless, go honk at Orackle, not hack in rpmdb/db3.c > > Yes I'm serious. All of the overrides in rpmdb/db3.c are > going away. But DB_CONFIG overrides the settings in rpmdb/db3.c, not the other way around.. I committed the changes to provide default values in case of missing DB_CONFIG. Ie. in new environments, such as when installing to a clean chroot, no /var/lib/rpm/DB_CONFIG leads to rpm using /var/lib/rpm for log directory, then later during package installation, the DB_CONFIG gets installed with different values, causing breakage due to log directory changing.. I first implemented a check for an existing /var/lib/rpm/DB_CONFIG in URPM, which would copy the /var/lib/rpm/DB_CONFIG outside of the chroot into it, but this was hacky and would also lead to it always taking precendence wrt. %config(noreplace) /var/lib/rpm/DB_CONFIG... -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
disttag/distepoch in RPMTAG_NVRA [Fwd: [Cooker] Warning: remaining bugs in RPM ? (no distro tag)]
For RPMTAG_NVRA to expand to using%{___NVRA}, I found myself
having to modify hGetNevra().
To make dbiFindMatches() to match -%{disttag}%{distepoch}, I changed
_post_NVRA to:
static const char _post_NVRA[] =
"(-[^-]+-[^-]+-[^-]+\\.[^.]+|-[^-]+-[^-]+\\.[^.]+|-[^-]+\\.[^.]+|\\.[^.]+|)$";
This expression gets too greedy for packages with '-' in the name and
without disttag/distepoch though..
ie. 'rpm -q foo' might return:
foo-1-1-mdv2011.0.x86_64
foo-bar-1-1mdv2011.0.x86_64
-- Forwarded message --
From: Jeff Johnson
Date: 2011/1/19
Subject: Re: [Cooker] Warning: remaining bugs in RPM ? (no distro tag)
To: coo...@mandrivalinux.org
On Jan 19, 2011, at 7:02 AM, Per Øyvind Karlsen wrote:
>>
>> I fail to understand "manually", nor is there a downside (as
>> long as RPM never has to look up localized package depedencies).
> To get %{NVRA} to return the same, the macro needs to be expanded in
> rpmdb/hdrfmt.c:hGetNevra()
> though. I've not been able to get the matching in dbiFindMatches() to
> work with it though..
>
Dunno why you are in hGetNevra(), but I'm sure that there's a fix.
I'd need a clearer explanation (on ) of what you need to suggest
or implement something.
73 de Jeff
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: disttag/distepoch in RPMTAG_NVRA [Fwd: [Cooker] Warning: remaining bugs in RPM ? (no distro tag)]
2011/1/20 Jeff Johnson :
>
> On Jan 19, 2011, at 7:45 AM, Per Øyvind Karlsen wrote:
>
>> For RPMTAG_NVRA to expand to using%{___NVRA}, I found myself
>> having to modify hGetNevra().
>>
>
> Why did you have to modify?
>
> While this setting is a huge mess, its _IS_ adequate to compose
> an "identification" string based on other tag data:
>
> %___NVRA
> %%{NAME}-%%{VERSION}-%%{RELEASE}%%|DISTTAG?{-%%{DISTTAG}%%|DISTEPOCH?{%%{DISTEPOCH}}|}|%%|ARCH?{.%%|SOURCERPM?{%%{ARCH}}:{src}|}:{}|
>
> I fail to understand why changes to hGetNevra() method are _ALSO_ needed.
>
>> To make dbiFindMatches() to match -%{disttag}%{distepoch}, I changed
>> _post_NVRA to:
>>
>> static const char _post_NVRA[] =
>> "(-[^-]+-[^-]+-[^-]+\\.[^.]+|-[^-]+-[^-]+\\.[^.]+|-[^-]+\\.[^.]+|\\.[^.]+|)$";
>>
>> This expression gets too greedy for packages with '-' in the name and
>> without disttag/distepoch though..
>>
>
> Yes _post_NVRA MUST be able to parse through variant (like N.A or N-V.A) forms
> using a pattern.
>
> If you can't write a pattern (usually as a tail anchor'es *RE, the usual
> parsing rule is that the last 2 '-' characters are GUARANTEED to surround V)
> for NVRA strings that include Disttag/Distepoch, well, you are likely screwed.
>
>> ie. 'rpm -q foo' might return:
>> foo-1-1-mdv2011.0.x86_64
>> foo-bar-1-1mdv2011.0.x86_64
>>
>
>
> Yep. Can't tell what's what because the syntax isn't predictable.
One workaround could be something like this:
if(keyp[0] != '^') {
Header h;
while((h = rpmmiNext(mi)) {
he->tag = RPMTAG_NAME;
if(headerGet(h, he, 0))
if(strlen(keyp) < strlen(he->p.str))
rpmmiPrune(mi,...);
}
This would remove the matches that has a name longer than the package
queried for.
Might not make immediate sense, I'll take a closer look tomorrow,
bedtime now. :)
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: disttag/distepoch in RPMTAG_NVRA [Fwd: [Cooker] Warning: remaining bugs in RPM ? (no distro tag)]
2011/1/20 Jeff Johnson :
>
> On Jan 19, 2011, at 8:44 PM, Jeff Johnson wrote:
>
>>
>> On Jan 19, 2011, at 8:39 PM, Per Øyvind Karlsen wrote:
>>
>>>>
>>>>> ie. 'rpm -q foo' might return:
>>>>> foo-1-1-mdv2011.0.x86_64
>>>>> foo-bar-1-1mdv2011.0.x86_64
>>>>>
>>>>
>>>>
>>>> Yep. Can't tell what's what because the syntax isn't predictable.
>>> One workaround could be something like this:
>>> if(keyp[0] != '^') {
>>> Header h;
>>> while((h = rpmmiNext(mi)) {
>>> he->tag = RPMTAG_NAME;
>>> if(headerGet(h, he, 0))
>>> if(strlen(keyp) < strlen(he->p.str))
>>> rpmmiPrune(mi,...);
>>> }
>>>
>>> This would remove the matches that has a name longer than the package
>>> queried for.
>>>
>>
>> strlen isn't a strong enough hint, there's equal length strings
>> that parse unambiguously too. Yoy're gonna need some restrictions
>
> s/un// (I said the opposite of what I meant to say).
>
>> on permitted characters in Disttag/Distepoch, just like Version/Release
>> cannot contain '-'.
Well, they already have, you're thinking about in addition?
>
> And rpmmiPrune() isn't the right solution to a parsing problem either.
>
> A join might work, but there's no way that can be stabilizied on
> --query paths to meet luser expectations. It was hard enough
> figgering a means for pattern queries.
>
> I'd focus on getting a better *RE in place. You want as much of
> a prefix stem as possible so that DB_PARTIAL takes effect.
I hate regexp.. :p
>
> E.g., a *RE that starts like this: ^.*...
> will end up reading every key because there is no prefix stem,
> nor is there any way I could figger to make DB_PARTIAL relative to end-of-key.
>
> Reading every key for ~4K package NVRA is _STILL_ less computational
> effort than loading every header, as you example above does just
> to find the argument to pass to rpmmiPrune(), so stay focussed
> on a pattern that matsches strings can be handed to a parser.
Hmm, this one isn't much better either?
--- rpmdb/rpmdb.c 2011-01-09 07:25:35.583778635 +0100
+++ /home/peroyvind/RPM/rpm/BUILD/rpm-5.3.8/rpmdb/rpmdb.c
2011-01-21 06:58:28.104131003 +0100
@@ -1418,7 +1418,7 @@ static rpmRC dbiFindMatches(dbiIndex dbi
/* Add ^...$ *RE anchors. Escape pattern characters. */
{ rpmTag tag = dbi->dbi_rpmtag;
rpmMireMode mode = RPMMIRE_PCRE;
- static const char _post_NVRA[] =
"(-[^-]+-[^-]+\\.[^.]+|-[^-]+\\.[^.]+|\\.[^.]+|)$";
+ static const char _post_NVRA[] =
"(-[^-]+-[^-]+-[^-]+\\.[^.]+|-[^-]+-[^-]+\\.[^.]+|-[^-]+\\.[^.]+|\\.[^.]+|)$";
const char * _pat;
switch (tag) {
@@ -2442,6 +2442,44 @@ assert(keylen == sizeof(hdrNum));
rpmRC rc;
rc = dbiFindMatches(dbi, keyp, &set);
+ if(((const char*)keyp)[0] != '^' && tag == RPMTAG_NVRA && set
!= NULL && set->count > 0) {
+ int xx;
+ size_t i;
+ size_t len = strlen(keyp);
+ size_t size = 0;
+ dbiIndex pdbi;
+ DBC *pdbc;
+ DBT k = DBT_INIT;
+ DBT v = DBT_INIT;
+
+ pdbi = dbiOpen(db, RPMDBI_PACKAGES, 0);
+ xx = dbiCopen(pdbi, dbiTxnid(pdbi), &pdbc, 0);
+
+ for(i = 0; i < set->count; i++) {
+ Header h;
+ uint32_t offset = _hton_ui(set->recs[i].hdrNum);
+
+ k.data = &offset;
+ k.size = sizeof(offset);
+ xx = dbiGet(dbi, pdbc, &k, &v, DB_SET);
+ h = headerLoad(v.data);
+ he->tag = RPMTAG_NAME;
+ if(headerGet(h, he, 0)) {
+ if(len >= strlen(he->p.str)) {
+ set->recs[size].hdrNum = set->recs[i].hdrNum;
+ set->recs[size].tagNum = set->recs[i].tagNum;
+ size++;
+ }
+ _free(he->p.ptr);
+ }
+ h = headerFree(h);
+ }
+ if(set->count != size) {
+ set->count = size;
+ set->recs = realloc(set->recs, size * sizeof(*set->recs));
+ }
+ xx = dbiCclose(pdbi, pdbc, 0);
+ }
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: disttag/distepoch in RPMTAG_NVRA [Fwd: [Cooker] Warning: remaining bugs in RPM ? (no distro tag)]
grf, sent this one earlier with wrong alias..
2011/1/25 Per Øyvind Karlsen :
> 2011/1/24 Jeff Johnson :
>> Lessess if we can get this "fixed".
>>
>> On Jan 19, 2011, at 8:39 PM, Per Øyvind Karlsen wrote:
>>>>
>>>>> To make dbiFindMatches() to match -%{disttag}%{distepoch}, I changed
>>>>> _post_NVRA to:
>>>>>
>>>>> static const char _post_NVRA[] =
>>>>> "(-[^-]+-[^-]+-[^-]+\\.[^.]+|-[^-]+-[^-]+\\.[^.]+|-[^-]+\\.[^.]+|\\.[^.]+|)$";
>>>>>
>>>>> This expression gets too greedy for packages with '-' in the name and
>>>>> without disttag/distepoch though..
>>>>>
>>>>
>>
>> There is something I don't understand here.
>>
>> Let's say a NVRA key looks like this
>>
>> foo-1.2-3mdv2011.0.noarch
>>
>> That might be a {N,V,R,A} 4-tuple, or that might be a {N,V,R,D,A} 5- or
>> 6-tuple.
>>
>> Either way the string is identical, and the existing _post_NVRA pattern
>> either "works" or doesn't.
>>
>> So where is this "too greedy" coming from? My guess is that you have
>> mixtures of strings in the NVRA index, some with "mdv2011.0", some without.
> Yupp, that's just it.
>>
>> Get rid of the mixture and you will get rid of the "too greedy".
> As disttag/distepoch is optional, it's not as easy as getting rid of
> packages without..
>
> Additional restrictions on allowed characters seems to be the way to go.
>
> I'm thinking something like this:
> %pattern_Disttag ^[a-z]+$
> %pattern_Distepoch ^[A-Z0-9.]+$
>
> Also a different character than '-' for separator, I don't have any
> specific character
> in mind myself yet though..
>
> --
> Regards,
> Per Øyvind
>
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: distepoch problem with latest snapshot of 5.2
2011/1/25 Matthew Dawkins :
>
>
> On Fri, Jan 14, 2011 at 11:05 AM, Matthew Dawkins
> wrote:
>>
>> I recently updated my snapshot of 5.2 to build around a perl upgrade to
>> 5.12.2, but I didn't expect any problems really.
>> Well pkgs that have requires like the following:
>> Provides: libpq = %{version}-%{release}
>>
>> now also have this half distepoch after it :2011.1
>>
>> made with a newer rpm5.2 snapshot
>> rpm -qp --provides lib64pq8.4_5-8.4.5-3-
>> unity2011.0.x86_64.rpm
>> postgresql-libs = 8.4.5-3
>> libpq = 8.4.5-3
>> lib64pq8.4_5-virtual = 8.4
>> libpq.so.5()(64bit)
>> lib64pq8.4_5 = 8.4.5-3:2011.0
>>
>> made with the older rpm5.2 snapshot
>> rpm -qp --provides lib64pq8.4_5-8.4.4-3-unity2010.x86_64.rpm
>> postgresql-libs = 8.4.4-3
>> libpq = 8.4.4-3
>> lib64pq8.4_5-virtual = 8.4
>> libpq.so.5()(64bit)
>> lib64pq8.4_5 = 8.4.4-3
>
> Funny how I get no responses on this problem. It looks pretty familiar
> to what's being reported on cooker hmmm
I've been occupied with getting the situation for cooker stabilized
and most crucially, getting
our buildsystem up and running without new issues.
With horrible spaghetti perl code in urpmi, various versions of both
rpm and URPM used on hosts
generrating metadata, mess of my own and general stress making the
situation more painful,
I'm only now starting to get there..
Meanwhile there's nothing preventing you from fixing this yourself
(I've already told you where and what
needs fixing), nor anything forcing you to switch to rpm 5.3 (in
contrast to cooker where I've already forced the change upon
everyone,making my priorities rather obvious).
I'll try get smart fixed over the next days..
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/lib/ rpmds.c
2011/1/25 Jeff Johnson : > This change MUST be tested and integrated somehow. I'm working on it, this is why my later commits are touching /tests. :) I'm about to push a new cvs snapshot to cooker with 'make check' (finally) enabled now, you should see some new regression tests following soon. :o) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: disttag/distepoch in RPMTAG_NVRA [Fwd: [Cooker] Warning: remaining bugs in RPM ? (no distro tag)]
2011/1/25 Jeff Johnson :
>
> On Jan 25, 2011, at 12:17 AM, Per Øyvind Karlsen wrote:
>
>> grf, sent this one earlier with wrong alias..
>> 2011/1/25 Per Øyvind Karlsen :
>>> 2011/1/24 Jeff Johnson :
>>>> Lessess if we can get this "fixed".
>>>>
>>>> On Jan 19, 2011, at 8:39 PM, Per Øyvind Karlsen wrote:
>>>>>>
>>>>>>> To make dbiFindMatches() to match -%{disttag}%{distepoch}, I changed
>>>>>>> _post_NVRA to:
>>>>>>>
>>>>>>> static const char _post_NVRA[] =
>>>>>>> "(-[^-]+-[^-]+-[^-]+\\.[^.]+|-[^-]+-[^-]+\\.[^.]+|-[^-]+\\.[^.]+|\\.[^.]+|)$";
>>>>>>>
>>>>>>> This expression gets too greedy for packages with '-' in the name and
>>>>>>> without disttag/distepoch though..
>>>>>>>
>>>>>>
>>>>
>>>> There is something I don't understand here.
>>>>
>>>> Let's say a NVRA key looks like this
>>>>
>>>> foo-1.2-3mdv2011.0.noarch
>>>>
>>>> That might be a {N,V,R,A} 4-tuple, or that might be a {N,V,R,D,A} 5- or
>>>> 6-tuple.
>>>>
>>>> Either way the string is identical, and the existing _post_NVRA pattern
>>>> either "works" or doesn't.
>>>>
>>>> So where is this "too greedy" coming from? My guess is that you have
>>>> mixtures of strings in the NVRA index, some with "mdv2011.0", some without.
>>> Yupp, that's just it.
>
> No, there's _STILL_ something I'm missing.
>
> Concatenated strings -- with or without Distepoch: --
> will "work" without any change.
>
> Can you supply an example where the existing implementation
> is "too greedy" for some input pattern applied to some set of strings?
ie:
rpm-build-1-1.x86_64
version: build, release: 1
vs
rpm-build-1-1mdv2011.0.x86_64
version: 1, release: 1
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: distepoch problem with latest snapshot of 5.2
2011/1/25 Jeff Johnson : > > On Jan 25, 2011, at 1:42 PM, Matthew Dawkins wrote: > > > On Tue, Jan 25, 2011 at 11:14 AM, Jeff Johnson wrote: >> >> On Jan 25, 2011, at 12:52 PM, Matthew Dawkins wrote: >> >> > >> > Unity != Mandriva >> > >> > The problem for Unity was that smart doesn't support it, nor does >> > createrepo (i'm guessing) >> > >> >> There's nothing to support with smart and/or createrepo if Distepoch: is >> finished. >> > > I'd like to see AFB's comments there, b/c we spoke about it at one point. > > > Comments are welcomed. But I can't reason from "No comment." to either > "No interest" or "No problem" any better than anyone else. >> >> Its all just smoke-and-mirrors to get a sounder basis for >> identification/branding, >> and to remove the need for %mkrel being configured during build's. >> > > I fully support the idea of what distepoch is supposted to be, but maybe > this is a question of more eating our own dog food than anything else? This > problem can't be spotted until rpms are built with rpm5 and the feature > being enabled. > > > Yes, usage is absolutely crucial. FWIW, I'm quite sure Mandriva would not be > attempting Distepoch: if UL had not succeeded already. > >> > A courtesy response is nice otherwise it feels like we are just getting >> > ignored for the better, more well planned mother project. It seems testing >> > and error report checking are a big todo there too! >> > >> >> Because Distepoch: is under >> #ifdef RPM_VENDOR_MANDRIVA >> I can't solve any issues directly. Just like filetriggers. >> >> What I have tried to do is to force the issue into RPM (or back to >> vendor's), >> and have asked for opinions on whether to include Distepoch: and file >> triggers >> directly in RPM or rip it out. >> >> I've heard exactly zero opinions on the vendor specific issues, all of >> which >> have been mapped into launcpad.net/rpm blueprint's for discussion. >> > > Usually no response means a couple things, don't know, don't care and no > objections. > Sorry for the no response, but there are no objections here. > >> >> My personal opinion is still conflicted wrto both Distepoch: and file >> triggers. >> >> But I cannot be blamed for "support" of vendor-peculier changes that I >> never see or use. >> > > Hmm maybe supporting those that take time to support you is a good practice. > I don't know how you think rpm5 will ever get huge traction if your default > support are for two platforms that will never support you, but the two > biggest platforms that support you aren't even on the menu. > > >> > I can't think of another project that has used and deployed rpm5 more >> > and our experiences are still chucked to the side like rubbish. TY >> > >> >> Rubbish? Chucked? If I'm at fault, please speak plainly and I will try to >> accomodate. >> > > I emailed you directly first. /me shrugs > > > If you're talking about the e-mail you sent ~10 days ago, I was contracting > at > a customer site with the flu. All I could do is curl up into a fetal > position evenings/weekends in > order to be ready for the next day's efforts. I was living on OJ and without > coffee or even solid food for about a week. That's life, or at leas was my > past > 2 week's. I'm still catching up and have to return next Monday. > >> My development focus is on rpm-5.4.x to get out of the way of Mandriva >> adopting rpm-5.3.x. >> >> And my previous devel focus was rpm-5.3.x to give UL a stable rpm-5.2.x. >> > > The reason we haven't adopted > 5.2.x is b/c we were never assured a problem > free upgrade path to 5.3.x nor were we assured that all the fixes that we > had worked so hard figuring out on 5.2.x were upstreamed. > > What passes for "assurance"? I've been using rpm-5.3.x for 1.5 years. And > I'm > most definitely _NOT_ going to attempt "compatible" with rpm-5.3.x, the > issues are too big and profound. > Meanwhile, the "conversion" isn't that hard, and I supplied all of the > details, > as well as running the conversion on the odd 10-15 linux distro boxes under > buildbot's and helped at lengtrh sort out the issue with Per Oyvind's > conversion > script being deployed in main/testing. > But I CANNOT support seamless drop-in "compatibility" going both forwards > and > backwards between rpm-5.3.7 <-> rpm-4.6.1. That was a deliberate and > conscious > non-goal of "RPM ACID" even though I deliberately made sure that the > conversion > was quite simple and straight forward. > > >> >> But that also means that I'm several steps away from fixing anything, and >> haven't >> any basis for a "release" or "fixing" or much else. >> > > Lil by lil, > > > ARe you interested in upgrading to "RPM ACID"? IDMS has managed that > conversion, > and Mandriva Cooker is there too as well. I should fairly easily be able to dig out and clean up the conversion code from URPM.xs to either fit in a independent tool or as a python module using python's C api to integrate with smart... But I just need to make my way there first, I can
Re: disttag/distepoch in RPMTAG_NVRA [Fwd: [Cooker] Warning: remaining bugs in RPM ? (no distro tag)]
2011/1/25 Jeff Johnson : > > On Jan 25, 2011, at 12:17 AM, Per Øyvind Karlsen wrote: > >>>> >>>> So where is this "too greedy" coming from? My guess is that you have >>>> mixtures of strings in the NVRA index, some with "mdv2011.0", some without. >>> Yupp, that's just it. > > OK ... ick. Truly its gonna be easier to retrofit _SOMETHING_ than > to try to figger missing values with patterns. > > All that's gonna happen is I'm gonna be forced to revert pattern lookup's. > >>>> >>>> Get rid of the mixture and you will get rid of the "too greedy". >>> As disttag/distepoch is optional, it's not as easy as getting rid of >>> packages without.. >>> >>> Additional restrictions on allowed characters seems to be the way to go. >>> >>> I'm thinking something like this: >>> %pattern_Disttag ^[a-z]+$ >>> %pattern_Distepoch ^[A-Z0-9.]+$ > > Hmmm ... these are likely too quirky. Distag: e.g. has pre-existing usages. But has any of these usages really ever been adopted? > >>> >>> Also a different character than '-' for separator, I don't have any >>> specific character >>> in mind myself yet though.. > > Yet Another Separator solves what problem? Why isn't '-' gud enuf? It would avoid having to revert pattern lookup. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/python/ header-py.c header-py.h rpmmodule....
d'oh, sent with wrong email address.. 2011/1/27 Per Øyvind Karlsen : > 2011/1/27 Jeff Johnson : >> There's a deep political rift aka labelCompare() involving missing values >> that needs to be sorted through here. >> >> The same political rift affects your "fix" with missing values (my comment >> was something arch like "You changed too many lines of code and there needs >> to be test cases first." I can find the explicit message if you don't recall) > I ended up reverting the change in lack of test cases though.. ;) >> >> The political rift is largely that the python script kiddies and >> labelCompare() >> are doing things differently than what RPM is doing. The issue is solely >> that there are different conventions for missing values that prevent >> otherwise identical code from being collapsed through re-factoring. >> >> But its not my job to teach script kiddies how to program or otherwise >> relieve them of their ignorance. Lord knows I've tried to do so for years >> and years and years. *shrug*. >> >> Meanwhile I no longer give a rat's ass crap about legacy. But you might want >> to coordinate the change with Ander's and smart before we have Yet Another >> Food Fight >> in the rpm-python cafeteria. > There's the obvious issue of legacy/API compatibilty, but how to deal with it > is hard to fully decide in the python bindings though, and practicality of > these > functions and benefit of getting same behaviour as RPM are hard to argue with > (regardless of smart, especially if wanting to support any different version > comparision scheme than using the order of EVRD). > The python bindings really should get some attention. first of all > just cleaning up > and fixing any existing issues. Moving past that, doing new > development on features > and functionality, legacy compatibility for bindings and/or any tools > (such as smart) > using them will both get painful if wanting to ensure compatibility > with ie. rpm.org > as well.. > > So yeah, implementing function in python bindings are trivial, the benefits > quite obvious, fitting it into smart OTOH will require more thinking, > discussion and > coordination.. For smart in Mandriva, I really want to make sure of consistent > behaviour with urpmi and rpm itself, which makes it important for me at least > to be able to switch back and forth between the two. > > -- > Regards, > Per Øyvind > __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/python/ header-py.c
2011/1/27 Jeff Johnson : > What is was the warning? If it was return value from headerFree() > being ignored, then try something simpler like Yupp, but I thought that I could cut down to just one assignment.. > > (void) headerFree(s->h); > s->h = NULL; > (headerFree is perfectly prepared to deal with NULL args, and there > are almost no cases in any rpm code where the rpmfooFree() return > is actually needed/used. See rpmio/url.c cache tear down for an example > of where the non-NULL is actually meaningfully used to eliminate ALL > references to force an actual free. There's another usage in Fclose(), > but be forewarned: > There are monsters in Fclose(). > > Note that your change can/will lead to s->h possibly > being non-null. headerFree() will return NULL iff > the refcount is 0. Ah, i thought that headerFree() would always return NULL, which is why I thought doing only one assignment would be cleaner.. I guess I should revert this one then.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/python/ header-py.c header-py.h rpmmodule....
2011/1/27 Anders F Björklund : > Jeff Johnson wrote: > >> There's a deep political rift aka labelCompare() involving missing values >> that needs to be sorted through here. > ... > >> Meanwhile I no longer give a rat's ass crap about legacy. But you might want >> to coordinate the change with Ander's and smart before we have Yet Another >> Food Fight >> in the rpm-python cafeteria. > > Here's my current implementation: > > Python: # ignore distepoch > C: /* ignore distepoch */ Do you have any code for it? I'm curious about how you parsed name, version, release etc. with/without disttag/distepoch > > Seems to "work" for EVR compare ? Well, it will make it ignore distepoch and working again at least, but I'd prefer for smart to actually support using it as well. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/python/ header-py.c header-py.h rpmmodule....
2011/1/27 Jeff Johnson : > > On Jan 27, 2011, at 2:25 PM, Anders F Björklund wrote: > >> Jeff Johnson wrote: >> >>> There's a deep political rift aka labelCompare() involving missing values >>> that needs to be sorted through here. >> ... >> >>> Meanwhile I no longer give a rat's ass crap about legacy. But you might want >>> to coordinate the change with Ander's and smart before we have Yet Another >>> Food Fight >>> in the rpm-python cafeteria. >> > > Thanks for comments. > >> Here's my current implementation: >> >> Python: # ignore distepoch >> C: /* ignore distepoch */ >> >> Seems to "work" for EVR compare ? >> >> Seriously, if you want to see the comparison change in Smart you should >> open a bug report (aka feature request) on Launchpad. Just like #697895 >> >> Otherwise it will use the same as now: >> - name >> - archcolor(arch) >> - vercmp(version) >> - archscore(arch) >> >> http://bazaar.launchpad.net/~smartpm/smart/trunk/view/head:/smart/backends/rpm/rpmver.py >> > > But the issue here is parallel to labelCompare() using rpmevrFoo methods. > > Parallel -- when different answers are returned because of missing value > conventions -- is in noone's interest imho. > > But that is the path that Per Oyvind is on with two different sets > of patches that are confusing different (and incompatible) missing value > conventions. > > I've avoided -- so far -- the need for any rpm-python discussion by leaving > labelCompare() > _EXACTLY_ as always. What hasn't changed will not break. Until Per Oyvind > starts > refactoring the code ;-) > > Yes its all very silly and stoopid. But I'll rot in hell before I get blamed > for > You broke yum by changing rpm-python @rpm5.org! > Which was the suggestion that Per Oyvind coordinate a tricky change first. Don't worry on labelCompare(), I find it rather inpractical and tedious to use compared to just passing EVR strings to evrCompare() for rpmEVRparse to take care of parsing it, rather than parsing it myself with ie. regexp and passing the parts of it as a tuple.. I'm afraid of touch existing functionality in the python bindings myself already anyways due to concern about legacy compatibility, by adding new functions I at least won't break anything existing, causing troubles for others.. ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/python/ header-py.c header-py.h rpmmodule....
2011/1/27 Jeff Johnson : > > On Jan 27, 2011, at 3:12 PM, Per Øyvind Karlsen wrote: > >>> >>> Yes its all very silly and stoopid. But I'll rot in hell before I get >>> blamed for >>> You broke yum by changing rpm-python @rpm5.org! >>> Which was the suggestion that Per Oyvind coordinate a tricky change first. >> Don't worry on labelCompare(), I find it rather inpractical and >> tedious to use compared >> to just passing EVR strings to evrCompare() for rpmEVRparse to take care of >> parsing it, rather than parsing it myself with ie. regexp and passing >> the parts of >> it as a tuple.. > > Well I delivered essentially that same statement to ssopw...@redhat.com > within 24 hours when he crufted up labelCompare() way back when. > > Life's too short to argue about whether 0 or NULL or "" or whatever is > The One Truly Pythonic Way to write code. > >> >> I'm afraid of touch existing functionality in the python bindings >> myself already anyways >> due to concern about legacy compatibility, by adding new functions I >> at least won't >> break anything existing, causing troubles for others.. ;) >> > > Hint: test cases. How convenient, I now can just convert the existing test case with labelCompare() in python/test/test_rpm.py to use evrCompare()! ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/python/ header-py.c header-py.h rpmmodule....
2011/1/27 Anders F Björklund : >>> Here's my current implementation: >>> >>> Python: # ignore distepoch >>> C: /* ignore distepoch */ >> Do you have any code for it? I'm curious about how you parsed name, >> version, release etc. >> with/without disttag/distepoch > > As sent to Unity... Why not just do 'rc = vercmppart(d1, d2);' when already parsing distepoch and passing it as a new argument to the functions? That's pretty much all that's needed for supporting distepoch in version comparision.. :) smart will still have an issue with composing the package name in ie. smart/backends/rpm/base.py: search() etc. due to the extra '-' in the name though.. ie. foo-1-2-2011.0.x86_64 will become: name: foo-1 verison = 2 release = 2011.0 arch = x86_64 -- Regards, Per Øyvind -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/python/ header-py.c header-py.h rpmmodule....
2011/1/27 Per Øyvind Karlsen : > 2011/1/27 Anders F Björklund : >>>> Here's my current implementation: >>>> >>>> Python: # ignore distepoch >>>> C: /* ignore distepoch */ >>> Do you have any code for it? I'm curious about how you parsed name, >>> version, release etc. >>> with/without disttag/distepoch >> >> As sent to Unity... > Why not just do 'rc = vercmppart(d1, d2);' when already parsing distepoch > and passing it as a new argument to the functions? > > That's pretty much all that's needed for supporting distepoch in version > comparision.. :) > > smart will still have an issue with composing the package name in ie. > smart/backends/rpm/base.py: search() etc. due to the extra '-' in the > name though.. Never mind , issue for me to fix with synthesis, been a while since I last looked at smart code.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
[PATCH] Using dependency type for ordering
I've tried to make a first attempt at resolving dependency loops using
the specific dependency type as hint for ordering.
The patch attached will try attempt resolving the loops by removing
one kind of dependency type (based on what seems likely to be the
most important kind of dependency wrt. ordering, correctness is
probably not 100% here), then rescanning for still existing loops,
then remove next kind of dependency, then rescan and on...
Dunno if this seems like a sane enough approach or not (or whether
implemented in the correct place or not), but it seems like a step in
the right direction at least. :)
WDYT?
--
Regards,
Per Øyvind
--- lib/order.c 2011-01-25 16:05:02.287333979 +0100
+++ /home/peroyvind/RPM/rpm/BUILD/rpm-5.3.8/lib/order.c 2011-02-01 18:33:06.607553037 +0100
@@ -332,7 +332,7 @@ static inline /*@observer@*/ const char
/*@-mustmod@*/ /* FIX: hack modifies, but -type disables */
static /*@owned@*/ /*@null@*/ const char *
zapRelation(rpmte q, rpmte p,
- int zap, /*@in@*/ /*@out@*/ int * nzaps, int msglvl)
+ int zap, /*@in@*/ /*@out@*/ int * nzaps, int msglvl, rpmuint32_t skipFlags)
/*@globals rpmGlobalMacroContext, h_errno, internalState @*/
/*@modifies q, p, *nzaps, rpmGlobalMacroContext, internalState @*/
{
@@ -361,6 +361,8 @@ zapRelation(rpmte q, rpmte p,
(void) rpmdsSetIx(requires, tsi->tsi_reqx);
Flags = rpmdsFlags(requires);
+ if(Flags & skipFlags)
+ continue;
dp = rpmdsNewDNEVR( identifyDepend(Flags), requires);
@@ -369,8 +371,8 @@ zapRelation(rpmte q, rpmte p,
*/
if (zap) {
rpmlog(msglvl,
- _("removing %s \"%s\" from tsort relations.\n"),
- (rpmteNEVRA(p) ? rpmteNEVRA(p) : "???"), dp);
+ _("removing %s \"%s\" from tsort relations.\n"),
+ (rpmteNEVRA(p) ? rpmteNEVRA(p) : "???"), dp);
rpmteTSI(p)->tsi_count--;
if (tsi_prev) tsi_prev->tsi_next = tsi->tsi_next;
tsi->tsi_next = NULL;
@@ -1812,6 +1814,18 @@ int _rpmtsOrder(rpmts ts)
int depth;
int breadth;
int qlen;
+static const evrFlags orderPriority[] = {
+ RPMSENSE_MISSINGOK,
+ RPMSENSE_SCRIPT_VERIFY,
+ RPMSENSE_PACKAGE,
+ RPMSENSE_FIND_REQUIRES,
+ _ERASE_ONLY_MASK,
+ _INSTALL_ONLY_MASK,
+ _ALL_REQUIRES_MASK
+}; /* dependency to zap in order to try resolve dependency loops */
+rpmuint32_t skipFlags = _ALL_REQUIRES_MASK;
+unsigned sfi = 0;
+
#endif /* REFERENCE */
if (_rpmts_debug)
@@ -2007,6 +2021,9 @@ fprintf(stderr, "--> %s(%p) tsFlags 0x%x
rescan:
if (pi != NULL) pi = rpmtsiFree(pi);
#endif
+if (sfi < sizeof(orderPriority))
+ skipFlags &= ~orderPriority[sfi++];
+
q = r = NULL;
qlen = 0;
pi = rpmtsiInit(ts);
@@ -2168,10 +2185,14 @@ rescan:
const char * nevra;
#endif
const char * dp;
+ /*
+ * TODO: use RPMLOG_DEBUG for when loops can be resolved
+ * without zapping all dependencies in it
+ */
rpmlogLvl msglvl = (anaconda || (rpmtsDFlags(ts) & RPMDEPS_FLAG_DEPLOOPS))
? RPMLOG_WARNING : RPMLOG_ERR;
#if defined(RPM_VENDOR_MANDRIVA) /* loop-detection-optional-loglevel */
- // Report loops as debug-level message by default (7 = RPMLOG_DEBUG), overridable
+ /* Report loops as debug-level message by default (7 = RPMLOG_DEBUG), overridable */
msglvl = rpmExpandNumeric("%{?_loop_detection_loglevel}%{?!_loop_detection_loglevel:7}");
#endif
@@ -2184,7 +2205,7 @@ rescan:
}
/* Find (and destroy if co-requisite) "q <- p" relation. */
- dp = zapRelation(q, p, 1, &nzaps, msglvl);
+ dp = zapRelation(q, p, 1, &nzaps, msglvl, skipFlags);
#if 0
/* Print next member of loop. */
Re: first try at rpm 5.3.8
2011/2/9 Jeff Johnson : > > On Feb 8, 2011, at 10:32 PM, Matthew Dawkins wrote: > >> Ok this is my first attempt at building a chroot with rpm-5.3.8-0.20110125.3. >> >> #Error after the basesystem + smart installed >> rpmdb: unrecognized name-value pair: set_create_dir >> error: db4 error(22) from dbenv->open: Invalid argument >> rpmdb: unrecognized name-value pair: set_create_dir >> error: db4 error(22) from dbenv->open: Invalid argument >> rpmdb: unrecognized name-value pair: set_create_dir >> error: db4 error(22) from dbenv->open: Invalid argument >> rpmdb: unrecognized name-value pair: set_create_dir >> error: db4 error(22) from dbenv->open: Invalid argument >> rpmdb: unrecognized name-value pair: set_create_dir >> error: db4 error(22) from dbenv->open: Invalid argument >> rpmdb: unrecognized name-value pair: set_create_dir >> error: db4 error(22) from dbenv->open: Invalid argument >> . > > You are not using db-5.1.19. There's some annoying syntax changes in > DB_CONFIG. > > For starters, just comment out the lines in /var/lib/rpm/DB_CONFIG. The log > files > won't be in a log/log.* subdirectory, nothing else matters. > > Have you run the dbconvert.sh script? using the new tools/dbconvert.c in stead is recommended and avoids the db51-utils dependency as well.. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/rpmdb/ rpmdb.c
2011/2/14 Jeff Johnson : > Hmmm ... rpmmiCount is supposed to be invoked lazily when needed, > not as part of every iteration. > > The conditions in rpmmiCount() may need adjustment. That I can > easily believe. in lib/psm.c:1666 rpmmiCount() is used, where rpmmiNext() has already created mi->mi_dbc without mi->mi_count being set. As mi->mi_dbc != NULL, mi->mi_count never gets set by rpmmiCount(), thus rpmmiCount() will always return 0. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/rpmdb/ rpmdb.c
2011/2/14 Jeff Johnson : > > On Feb 13, 2011, at 9:41 PM, Per Øyvind Karlsen wrote: > >> 2011/2/14 Jeff Johnson : >>> Hmmm ... rpmmiCount is supposed to be invoked lazily when needed, >>> not as part of every iteration. >>> >>> The conditions in rpmmiCount() may need adjustment. That I can >>> easily believe. >> in lib/psm.c:1666 >> >> rpmmiCount() is used, where rpmmiNext() has already created mi->mi_dbc >> without mi->mi_count being set. >> > > OK. > > So move rpmmiCount() out of the iteration loop in psm.c:1666 instead of > muck about in rpmmiNext() is what I would try. I tried that first, but that resulted in some deadlock for which I could only kill rpm with -SIGKILL... -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/rpmdb/ rpmdb.c
2011/2/14 Jeff Johnson : > > On Feb 13, 2011, at 10:15 PM, Jeff Johnson wrote: >> >> Hmm the rpmiPrune() just above psm.c:1666 might need to >> looked at ... until yesterday it really dinna matter whether >> %trigger's worked beyond the toy test cases I originally >> wrote when implementing. Its probably ok, rpmmiPrune() is used >> heavily in lib/depends.c. But rpmmiPrune() affects rpmmiCount() >> in non-trivial ways now that there's no array of "join keys" >> to prune. >> > > Nah its not okay, the trigger counts are likely fubar for > any complex (i.e. more than 1) trigger firing based on patterns. > > The intent with rpmmiPrune() was to avoid already processed > headers when headerLoad() was far more expensive an operation than it > is in "RPM ACID". But rpmmiPrune() and rpmmiCount() are going > to interact in some very complex ways. > > Since headerLoad() is rather lightweight, a simple continue within > the iterator can be done instead for headers that have already been processed. > > Make sense? > > I'll get this fixed in the next couple of days (took 2 days to rsync 2011.0 > packages this weekend, sigh. But I should be able to keep up w Cooker > because of rsync more easily). > > And no I'm not subscribed to , my reply bounced. it's an open list, just a matter of subscribing :) -- Regards. Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/rpmdb/ rpmdb.c
2011/2/14 Per Øyvind Karlsen :
> 2011/2/14 Jeff Johnson :
>>
>> On Feb 13, 2011, at 9:41 PM, Per Øyvind Karlsen wrote:
>>
>>> 2011/2/14 Jeff Johnson :
>>>> Hmmm ... rpmmiCount is supposed to be invoked lazily when needed,
>>>> not as part of every iteration.
>>>>
>>>> The conditions in rpmmiCount() may need adjustment. That I can
>>>> easily believe.
>>> in lib/psm.c:1666
>>>
>>> rpmmiCount() is used, where rpmmiNext() has already created mi->mi_dbc
>>> without mi->mi_count being set.
>>>
>>
>> OK.
>>
>> So move rpmmiCount() out of the iteration loop in psm.c:1666 instead of
>> muck about in rpmmiNext() is what I would try.
> I tried that first, but that resulted in some deadlock for which I could only
> kill rpm with -SIGKILL...
Would this patch be better? :)
--
Regards,
Per Øyvind
--- rpm-5.3.8/rpmdb/rpmdb.c.rpmmi_next~ 2011-02-15 22:24:26.690003947 +0100
+++ rpm-5.3.8/rpmdb/rpmdb.c 2011-02-16 15:19:28.830004006 +0100
@@ -1630,22 +1630,26 @@ fprintf(stderr, "<-- %s(%p) rc %u\n", __
unsigned int rpmmiCount(rpmmi mi)
{
unsigned int rc;
+int initDbc;
/* XXX Secondary db associated with Packages needs cursor record count */
-if (mi && mi->mi_primary && mi->mi_dbc == NULL) {
+if (mi && mi->mi_primary && ((initDbc = mi->mi_dbc == NULL) || mi->mi_count == 0)) {
dbiIndex dbi = dbiOpen(mi->mi_db, mi->mi_rpmtag, 0);
DBT k = DBT_INIT;
DBT v = DBT_INIT;
int xx;
+ if(initDbc) {
assert(dbi != NULL); /* XXX dbiCopen doesn't handle dbi == NULL */
- xx = dbiCopen(dbi, dbiTxnid(dbi), &mi->mi_dbc, mi->mi_cflags);
+ xx = dbiCopen(dbi, dbiTxnid(dbi), &mi->mi_dbc, mi->mi_cflags);
+ }
k.data = mi->mi_keyp;
k.size = (u_int32_t)mi->mi_keylen;
if (k.data && k.size == 0) k.size = (UINT32_T) strlen((char *)k.data);
if (k.data && k.size == 0) k.size++; /* XXX "/" fixup. */
if (!dbiGet(dbi, mi->mi_dbc, &k, &v, DB_SET))
xx = dbiCount(dbi, mi->mi_dbc, &mi->mi_count, 0);
- mi->mi_dbc = NULL;
+ if(initDbc)
+ mi->mi_dbc = NULL;
}
rc = (mi ? mi->mi_count : 0);
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/rpmdb/ rpmdb.c
2011/2/14 Jeff Johnson : > > On Feb 13, 2011, at 10:56 PM, Per Øyvind Karlsen wrote: > >>> >>> And no I'm not subscribed to , my reply bounced. >> it's an open list, just a matter of subscribing :) >> > > You assume I know more than I do. Until you mentioned, I had no idea. > > And I still don't know what list is where even if open. send 'subscribe maintainers' to sy...@mandriva.com (IIRC). -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/macros/ mandriva.in
2011/2/22 Jeff Johnson : > Note that there's literally no frigging reason known > to the human race why RPM needs to supply absolute paths > to every bleeping uglix executable on all possible > platfomrs "protably" in spite of FHS and linux vendor > induced rearrangements. > > The proper (and entirely consistent with uglix tool box paradigms) > is to use PATH and write build recipes assuming that PATH is set > correctly. > > Its also not too hard to generate the macro settings dynamically, > using which and some simple echo's. Its just *INSANE* to > track all these paths into @rpm5.org CVS with vendor peculier > "Have it your own way!" configuration delivered as drop-in > through One Size Fits All Uglixes (with a whopping amount > of AutoFu pain). > > There's only a handful of toolchain related (I'm talking > CPU-VENDOR-OS-GNU-gcc > here) that are usefully configured in macros. > > grep == grep *shrug* > > But you might want to noodle up the script using > which/echo that dynamically generates a list > of absolute paths to executables that you deem > important instead. I personally try avoid use of these macros myself, but there's always someone who will compulsively use them, and for those the notion of the paths of those being broken are rather hard to contend.. ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpmpopt.in
2011/2/24 Jeff Johnson : > Nice! > > I see you wussed out re macro expansion. ;-) Yeah.. :| Was gonna look into something else, so I just wussed out and commited what was requested so that it at least wasn't forgotten (too st00pid to figure out in less than a few seconds).. :p -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: ruby @ rpm
2011/2/24 Tobias Gerschner :
> Good Morning,
>
> I've just asked Jeff and Ralf for write access to the cvs repository of rpm.
> I just like to briefly introduce me and what my motivation is on
> participating with rpm development.
> Being the lead dev of the yoper linux distribution for a couple of years I
> had my fair share of dealings with rpm and while its a great piece of
> software it's been abused beyond reach ( in Jeffs words : have it your way )
> and has from my point of view conceptually not evolved for some years
> (IMHO) because of too many directions its been pulled to.
> To see the progress of rpm5 over its short lifetime has been great and it
> has always been bugging me that I am not contributing. After a recent
> vacation I came with new strength and tackled an idea that's been floating
> between Matthew Dawkins and me for a few years by now. Details can be found
> here, with an excellent writing from Derrick Devine
> . http://unity-linux.org/unity-and-yoper-a-tale-of-two-distros/ . For the
> technically minded please read through to the end to the links section
> That is where I'll see my main focus over this year and as with openpkg
> we're a stakeholder in how RPM evolves and would not only like to demand but
> also give something back.
> Personally I want to focus on getting a feature into rpm which I believe
> would have a great impact on the (ab)usability of rpm. I believe it is
> feasible to use the FHS standard to create a templating system that allows -
> in a very flexible way - the extension of the spec file markup %package and
> related %files. Seeing that there is a filetrigger implementation ( great
> improvement btw!) it should be possible to fire that off optionally during
> e.g. __os_install_post to expand the list of packages and dynamically
> populate a new subset of packages purely based on file presence in
> %{buildroot}.
> I've tossed the idea around for a year by now, but never gotten around to
> working on it. I am not much of a C programmer to be honest, but I could
> pick that up over time. In the meantime I'll focus on the ruby elements of
> rpm and will happily fix anything that's reported broken - be it code or
> concept.
> However, I am pretty fluent in ruby and since it's a great language for
> modelling and prototyping I believe it is a good match to get new ideas into
> an rpm branch quickly before considering implementation in head.
> I know that Eric has been working on ruby bindings over the last year and
> maybe there's another chance for collaboration / reflection etc.
> I'll be happily abused along the way if you have any comments or input.
Welcome aboard, I look forward to see you clean up my fugly ruby code
soon. ;)
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
assertion error when trying to install repackaged packages
When trying to install a repackaged rpm, it will abort with an
assertion error due to
the presence of a %{removetid} tag:
assert(headerIsEntry(h, RPMTAG_REMOVETID) == 0);/* XXX sanity */
Where's the sanity in this as referred to in the comment? ;)
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
different suggests behaviour
Working out some remaining issues in perl-URPM for dealing with upgrades from stable releases I became aware of some different behaviour for suggests giving headaches.. First of all, ie. 'rpm -q --requires foo' will return both "regular" requires and suggests, is this really correct behaviour? For rpm 4.6 it will also treat the suggests as "regular" requires as well, ie. trying to install packages built with rpm 5.3 without satisfying suggests will return in dependency error. I'm not sure about what's considered as "correct" behaviour or not, working around it in perl-URPM can be done.. IMHO 'rpm -q --requires' shouldn't return soft dependencies, and older rpm versions shouldn't treat these as such either, ignorance of not knowing better being fairly obvious.. ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/build/ reqprov.c
2011/3/6 Jeff Johnson :
> Under #ifdef RPM_VENDOR_MANDRIVA please.
>
> The problem you are trying to solve is with aliasing
> for a package identifier, which sometimes has
> Distepoch: and sometimes does not?
Yes, primarily to treat EVR as being duplicate independent of distepoch
or not.
The second purpose is to remove duplicates of NEVR so that they get
removed in stead, ensuring NEVR to always be the last item of
%{provide{name,flags,version}}.
>
> If so the patch is mostly in the right place, but a "real"
> solution will be to decide on convention(s) for
> RPMTAG_NAME this is used solely for identification
> RPMTAG_PROVIDENAME this is used solely for assertions
> What is confusing is that those two usage cases have exactly the same string
> values, and adding Distepoch: has confused matters a bit (not in an important
> way).
>
> The convention(s) (that need to be finalized) are implemented
> when RPMTAG_PROVIDENAME is added to a header, not here, where
> you are essentially substituting one alias for the other
> where the real need (imho) is to split "identification" <-> "assertion"
> name spaces cleanly.
But distepoch is for both identification and assertion though..
>
> Gud enuf for now, and until there's clarity on Distepoch: conventions.
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/build/ reqprov.c
using right address this time..
2011/3/6 Per Øyvind Karlsen :
> 2011/3/6 Jeff Johnson :
>>
>> On Mar 6, 2011, at 9:42 AM, Jeff Johnson wrote:
>>
>>> Under #ifdef RPM_VENDOR_MANDRIVA please.
>>>
>>> The problem you are trying to solve is with aliasing
>>> for a package identifier, which sometimes has
>>> Distepoch: and sometimes does not?
>>>
>>> If so the patch is mostly in the right place, but a "real"
>>> solution will be to decide on convention(s) for
>>> RPMTAG_NAME this is used solely for identification
>>> RPMTAG_PROVIDENAME this is used solely for assertions
>>> What is confusing is that those two usage cases have exactly the same string
>>> values, and adding Distepoch: has confused matters a bit (not in an
>>> important way).
>>>
>>> The convention(s) (that need to be finalized) are implemented
>>> when RPMTAG_PROVIDENAME is added to a header, not here, where
>>> you are essentially substituting one alias for the other
>>> where the real need (imho) is to split "identification" <-> "assertion"
>>> name spaces cleanly.
>>>
>>> Gud enuf for now, and until there's clarity on Distepoch: conventions.
>>>
>>
>> Let me underscore what I think needs to be decided.
>>
>> Distepoch: (and Disttag:) are adding "branding" identifiers. That's
>> fine for identification purposes.
>>
>> WHat hasn't been decided is this:
>> Do you want "branding" throughout assertions too?
>>
>> i.e. should Distepoch: be added to all dependencies as well as to {N,E,V,R}.
> I prefer for it to be added in same fashion as epoch, it being the least
> significant value, omitting it for provides only using %{version}-%{release}
> provides EVR will then be okay as well if one wants.
>
> I at least personally prefer this logic to be mostly consistent with the rest,
> and also easiest to grasp and packagers to customize.
>>
>> Th benefit of adding is that RPM then continues with identically valued
>> strings for WYSIWYG meeting package monkey expectations.
>>
>> The cost(s) of adding "branding" like Distepoch: to assertions are:
>> 1) all package dependencies written in *.spec will need to be changed.
>> 2) depsolver metadata is gonna increase in size with lots and lots of
>> redundant "branding" strings.
> Mostly just adding it to package NEVR only is sufficient for achieving both
> main goals of "identification" and "upgrade".
> Leaving it to packagers to add it to EVR of other provides as they see
> fit seems sensible enough to me at least. :)
>>
>> There's no reason a priori why RPMTAG_PROVIDENAME MUST include Distepoch:
>> except
>> to conform with expectations. Maybe I should encode all dependency strings
>> in EBCDIC
>> to prove that point ;-)
>>
>> Either approach is fine. But atm its all kinda muddled and ad hoc and in
>> need of clarity.
>
> --
> Regards,
> Per Øyvind
>
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/tests/ test-excludeunpackagedfile.spec
2011/3/9 Jeff Johnson : > Nice! And timely! But this behaviour is wrong! Why would one add additional functionality to a long existence %exclude attribute to do the same as what already can be done by using 'rm -rf'? And what if one intended to only exclude the file from being archived with that specific package, but not from every one (ie. still desired to do unpackaged file check on it) And what's the sanity behind using %exclude skip file from unpackaged files check for specific packages? "Yes, for the packages 'foo' and 'bar', 'foo' is the package that wants to skip the unpackaged file check the most!" It makes no sense, if %exclude were actually intended for that purpose, it would've made a *lot* more sense to not require for it to be used on per-package basis! %exclude only gets included in the list of packaged files because it's being passed as a file with a special attribute to *not* archive in that specific package. The unpackaged files check didn't know anything about these attributes and treats files as files.. Here's one previous reference to the topic being discussed earlier as well: http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2007-July/019221.html Pleeeaaseee don't make me having to try explain the logics and cause of the specific bug that's not really in our rpm version even to begin with. gaaah! -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: RPM not returning a failure code on some operations?!
sent with wrong address.. 2011/3/17 Per Øyvind Karlsen : > 2011/3/15 Jeff Johnson : >> I need to revisit the rpmgi pretty soon anyways, because >> hdlists-as-used-by-mandriva >> aren't the same as hdlists-as-used-by-rpm and its almost time to >> fix (Mandriva's not rpm's) divergence. > The format contains some extra padding and information to create an archive > to allow for seeking within it. > > $ perldoc MDV::Packdrakeng: > ... > IMPLEMENTATION > Compressed data are stored by block. For example, > > UncompresseddatA1UncompresseddatA2 UncompresseddatA3UncompresseddatA4 > |--- size 1 ---||--- size 2 ---| |--- size 3 ---||--- size 4 ---| > |<-offset1 |<-offset2 |<-offset3 |<-offset4 > > gives: > > CompresseD1CompresseD2 CompresseD3CompresseD4 > |--- c. size 1, 2 ---| |--- c. size 3, 4 ---| > |<-c. offset 1, 2 |<-c. offset 3, 4 > > A new block is started when its size exceeds the "block_size" value. > > Compressed data are followed by the table of contents (toc), > that is, a simple list of packed files. Each file name is terminated > by the "\n" character: > > dir1 > dir2 > ... > dirN > symlink1 > point_file1 > symlink2 > point_file2 > ... > ... > symlinkN > point_fileN > file1 > file2 > ... > fileN > > The file sizes follows, 4 values are stored for each file: > offset into archive of compressed block, size of compressed block, > offset into block of the file and the file's size. > > Finally the archive contains a 64-byte trailer, about the toc > and the archive itself: > > 'cz[0', strings 4 bytes > number of directory, 4 bytes > number of symlinks, 4 bytes > number of files, 4 bytes > the toc size, 4 bytes > the uncompression command, string of 40 bytes length > '0]cz', string 4 bytes > ... > > -- > Regards, > Per Øyvind > __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parseFiles.c
2011/3/23 Jeff Johnson : > This is a reversion from what was intended and already implemented > almost 4 years ago. > > Under #ifdef RPM_VENDOR_MANDRIVA please. So %clean shouldn't be run by default if not added to .spec? As %clean is a preferred default, it would seem backwards not having it invoked by default when not added to spec.. I can add under #ifdef, but it kinda seems like a strange default behaviour.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parseFiles.c
2011/3/23 Jeff Johnson :
>
> On Mar 23, 2011, at 4:51 PM, Jeff Johnson wrote:
>
>> This is a reversion from what was intended and already implemented
>> almost 4 years ago.
>>
>> Under #ifdef RPM_VENDOR_MANDRIVA please.
>>
>
> Since your first question is likely:
> OK where is it?
>
> The murky path to automated (and configurable) %clean
> starts in build/parseBuildInstallClean.c:
>
> } else if (parsePart == PART_CLEAN) {
> const char * s =
> rpmExpand("%{?__spec_clean_body}%{!?__spec_clean_body:%{?buildroot:rm -rf
> '%{buildroot}'\n}}\n", NULL);
> if (s && *s)
> *iobp = rpmiobAppend(*iobp, s, 0);
> s = _free(s);
> #if !defined(RPM_VENDOR_OPENPKG) /* still-support-section-clean */
> /* OpenPKG still wishes to use "%clean" script/section */
> iobp = NULL; /* XXX skip %clean from spec file. */
> #endif
> }
>
>
> Define %__spec_clean_body instead, don't bother messing with
> the parser state machine using PART_CLEAN (the spcfile parser is mostly
> crap anyways: PART_FOO linearizes the parser states
> and not a whole lot more that is useful or savable).
Yes, but this isn't run unless %clean exists in the spec file..
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parseFiles.c
2011/3/23 Jeff Johnson : > > On Mar 23, 2011, at 5:01 PM, Per Øyvind Karlsen wrote: > >>> >> Yes, but this isn't run unless %clean exists in the spec file.. >> > > Not true (from 4+ year old memory). But I've forgot. Well, your memory seems to be wrong then.. ;) This is the reason why I've not yet ripped out %clean from any spec files yet in cooker... > > PART_CLEAN (because its compiled in) is my major objection. > I also see no need for overrides and all the usual stuff > hardwired into rpmbuild. The crap will break endlessly > and there's not much reason (imho) or rpmbuild to undertake > rm -rf /some/path > because there's risk (when macros are involved) of crafting > a malicious *.spec that can/will achieve: > rm -rf ~ > The start of avoiding that is to rip %clean, continues through > making %__spec_clean_body RDONLY, and finishes up (after the > usual 5 years of silly bikeshed discussion) in hardwiring > a standard sensible default operation. Yes, but ripping out %clean would prevent %__spec_clean_body from being run, which this change fixed. > > Do you _REALLY_ need a tool to clean up *everything* with luser > overrides? > > From memory: > Look for Michael Jennings description of %clean implemented > in rpm-4.4.7 way back when. Might be on the old > rpm-devel list at dulug.duke.edu too. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parseFiles.c
2011/3/24 Jeff Johnson : > > On Mar 23, 2011, at 5:19 PM, Per Øyvind Karlsen wrote: > >> 2011/3/23 Jeff Johnson : >>> >>> On Mar 23, 2011, at 5:01 PM, Per Øyvind Karlsen wrote: >>> >>>>> >>>> Yes, but this isn't run unless %clean exists in the spec file.. >>>> >>> >>> Not true (from 4+ year old memory). But I've forgot. >> Well, your memory seems to be wrong then.. ;) > > Maybe. Do you remember code you wrote 4 years ago? > >> This is the reason why I've not yet ripped out %clean from >> any spec files yet in cooker... > > Under #ifdef RPM_VENDOR_MANDRIVA until I get a chance to > reload my neurons please. > >>> >>> PART_CLEAN (because its compiled in) is my major objection. >>> I also see no need for overrides and all the usual stuff >>> hardwired into rpmbuild. The crap will break endlessly >>> and there's not much reason (imho) or rpmbuild to undertake >>> rm -rf /some/path >>> because there's risk (when macros are involved) of crafting >>> a malicious *.spec that can/will achieve: >>> rm -rf ~ >>> The start of avoiding that is to rip %clean, continues through >>> making %__spec_clean_body RDONLY, and finishes up (after the >>> usual 5 years of silly bikeshed discussion) in hardwiring >>> a standard sensible default operation. >> Yes, but ripping out %clean would prevent %__spec_clean_body from >> being run, which this change fixed. > > Are you prepared to rip out %clean everywhere in Mandriva *.spec? > Go for it! You do have 79Gb of subversion with thousands > of packages and a systemd deployment and ... I'm > not at all sure how/why ripping %clean becomes important > after a beta release. No, I'm not saying that I'm even planning on actively ripping out %clean everywhere, but I do have started ripping out other things like %defattr, BuildRoot: etc. every now and then. I'm just arguing that's why I haven't ripped it out from any package anywhere at all yet because of this. > > It would help if you stated your intent(s) first. I'm real tired > about being blind sided and having to reactively argue > about whether I have Alzheimers's or not. Its > not up to my memory ... I thought my intent was obvious, I was fixing a behaviour that we both seem to agree on that would not be the desired behaviour, right? ie. a bug fix.. > > The change was discussed and published and vetted and was acceptible > at the time. Of course the bikeshed fussed "legacy compatible" > for weeks ... whatever. Then I don't get the issue, the correct behaviour should be the following: no %clean in spec == %__spec_clean_body is executed at end of build right? > >>> >>> Do you _REALLY_ need a tool to clean up *everything* with luser >>> overrides? >>> >>> From memory: >>> Look for Michael Jennings description of %clean implemented >>> in rpm-4.4.7 way back when. Might be on the old >>> rpm-devel list at dulug.duke.edu too. >> > > I will look for you. todo++. > > 73 de Jeff >> -- >> Regards, >> Per Øyvind >> __ >> RPM Package Manager http://rpm5.org >> Developer Communication List rpm-devel@rpm5.org > > __ > RPM Package Manager http://rpm5.org > Developer Communication List rpm-devel@rpm5.org > __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: RPM+Augeas -> Cooker?
d'oh, used wrong sender.. 2011/3/24 Per Øyvind Karlsen : > 2011/3/24 Jeff Johnson : >> Cool! Cooker finally has an Augeas package in main! >> >> The issue with the rpm+augeas embedding is that augeas >> development is pretty active, with lots of patterns >> in lenses and more. SO I did an implementation >> against the git check-out in order to keep up. >> >> Augeas is just starting to get picked up by distros like Cooker, >> so it is difficult to design the AutoFu to Just Work because there >> isn't any clear reference point with a "released" version. >> >> Now there is a reference point: augeas in cooker devel >> >> Note that augtool is/was the basis (as a nicely designed CLI tool) for >> all of the embeddings in RPM. And the embedding used in RPM isn't >> really any different than the libffi in the Python augeas bindings. >> Nother are quite simple to do because of the excellently designed augtool >> "high level" library API. >> >> Per Oyvind: Would you like to try RPM+Augeas in Cooker? You are the >> maintainer, I'm just the asshole here ;-) > I need to read up on it, but I don't mind if you go ahead try it, I'm feeling > that I'm lagging behind you enough already trying to keep up, while having > other things to do as well.. :| > > While I'm having "main responsibility" for rpm in cooker context and such, > I certainly wouldn't mind if you and/or Pinto Elia want to share > the maintenance of rpm stuff in cooker. I have other responsibilities as > well, so I'd be overexcited and reliefed by having more active help on > cooker directly. :) >> >> (aside) >> If you could also arrange to link against the OSSP uuid in >> the Cooker packaging, I can start demonstrating how >> UUID's can be used for package "identification". >> >> Sound like a plan? > Sure. :) > __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: RPM+Augeas -> Cooker?
2011/3/24 Jeff Johnson : > > On Mar 24, 2011, at 12:40 PM, Per Øyvind Karlsen wrote: > >> d'oh, used wrong sender.. >> 2011/3/24 Per Øyvind Karlsen : >>> 2011/3/24 Jeff Johnson : >>>> Cool! Cooker finally has an Augeas package in main! >>>> >>>> The issue with the rpm+augeas embedding is that augeas >>>> development is pretty active, with lots of patterns >>>> in lenses and more. SO I did an implementation >>>> against the git check-out in order to keep up. >>>> >>>> Augeas is just starting to get picked up by distros like Cooker, >>>> so it is difficult to design the AutoFu to Just Work because there >>>> isn't any clear reference point with a "released" version. >>>> >>>> Now there is a reference point: augeas in cooker devel >>>> >>>> Note that augtool is/was the basis (as a nicely designed CLI tool) for >>>> all of the embeddings in RPM. And the embedding used in RPM isn't >>>> really any different than the libffi in the Python augeas bindings. >>>> Nother are quite simple to do because of the excellently designed augtool >>>> "high level" library API. >>>> >>>> Per Oyvind: Would you like to try RPM+Augeas in Cooker? You are the >>>> maintainer, I'm just the asshole here ;-) >>> I need to read up on it, but I don't mind if you go ahead try it, I'm >>> feeling >>> that I'm lagging behind you enough already trying to keep up, while having >>> other things to do as well.. :| >>> >>> While I'm having "main responsibility" for rpm in cooker context and such, >>> I certainly wouldn't mind if you and/or Pinto Elia want to share >>> the maintenance of rpm stuff in cooker. I have other responsibilities as >>> well, so I'd be overexcited and reliefed by having more active help on >>> cooker directly. :) >>>> >>>> (aside) >>>> If you could also arrange to link against the OSSP uuid in >>>> the Cooker packaging, I can start demonstrating how >>>> UUID's can be used for package "identification". >>>> >>>> Sound like a plan? >>> Sure. :) > > BTW, expect some bit rot when you get to -laugeas. Augeas > was NICETOHAVE untikl yesterday ;-) > > Nothing will be too hard to fix, David Lutterkort has designed a > nice API into Augeas, just that "configuration management" > is a never ending battle and there's endless details to fiddle > with. > > Biut with a stable reference target to shoot at, well, > it won't be too hard to get augeas embedded into RPM. > > > I'll write up some toy test cases for tests/ "make check". > > Basically the embedding is one-to-one with augtool(8) so > you can probably wing it with "man augtool" I've just commited support, will submit a new rpm build with it enabled shortly.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ configure.ac
2011/3/24 Jeff Johnson : > Nice! > > Hacks == hacks (the uuid_t on Mac OS X is dreadfully annoying). > > Thanks for -luuid! Now I can write up how to > use (original work was ~ May, 2008 on archives if > interested) I've commited some various fixes for ossp_uuid for it to build, work properly without conflicts and also pass all regression tests as well: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/ossp_uuid/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpmqv.c
2011/3/27 Jeff Johnson : > This patch (and devzero's change) make no sense. > > rpm -ba is _ALWAYS_ in short-cicuit mode by definition, because > the starting point for --short-circuit is a non-existent directory > and nothing is built. > > The --short-circuit is to resume a build from a partially built tree > at a given point and run to completion. > > Dare I ask? > WTF do you want --short-circuit with -ba?!? Because some script > has decided to _ALWAYS_ add --short-circuit? That's stoopid ... Because I was thinking of -ba to have similar expected behaviour as -bb + -bs. Ie. I've made the false assumption when doing 'rpm -ba --short-circuit', where rpm did the complete build process rather than just -bb.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/build/ reqprov.c
2011/4/1 Jeff Johnson : > Under #ifdef RPM_VENDOR_MANDRIVA please. It already is. ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES build.c
2011/4/5 Jeff Johnson : > No way Jose! > > rpmbuild (and *.rpm metadata) can NOT have any encoding > assumed. > > Encoding is for DISPLAY, not for octets. > > Put unicode into package metadata at your own peril. > > Meanwhile -- without an means to specify encoding in metadata -- > rpm in C has *ONLY* 8 bit clean octet's and the usual conventions > for NUL terminated strings. > > Until there's a well defined means of specifying encoding for all > tag strings -- and that's a fundamental design change to *.rpm packaging that > likely will NEVER happen -- the problem simply CANNOT be fixed to meet naive > luser expectations, and all attempts to "fix" anything > are just doomed. > > C has octest, not utf8, and rpmdb strings are _NOT_ based on LC_ALL > and other i18n/l10n conventions. > > You can of course put whatever garbage you wish into strings that > will be stored as keys in an rpmdb, subject to all the usual > GIGO conventions distro's wish to inflict upon their customers. Okay, my mistake anyways, I was looking into an issue with unicode strings, then I specified wrong locale when testing. I notice now that with properly specified locale, it accepts unicode characters. Still though, using '%description -l', descriptions disappears.. :| -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES build.c
2011/4/5 Jeff Johnson : > > On Apr 5, 2011, at 3:49 PM, Per Øyvind Karlsen wrote: > >> 2011/4/5 Jeff Johnson : >>> No way Jose! >>> >>> rpmbuild (and *.rpm metadata) can NOT have any encoding >>> assumed. >>> >>> Encoding is for DISPLAY, not for octets. >>> >>> Put unicode into package metadata at your own peril. >>> >>> Meanwhile -- without an means to specify encoding in metadata -- >>> rpm in C has *ONLY* 8 bit clean octet's and the usual conventions >>> for NUL terminated strings. >>> >>> Until there's a well defined means of specifying encoding for all >>> tag strings -- and that's a fundamental design change to *.rpm packaging >>> that >>> likely will NEVER happen -- the problem simply CANNOT be fixed to meet naive >>> luser expectations, and all attempts to "fix" anything >>> are just doomed. >>> >>> C has octest, not utf8, and rpmdb strings are _NOT_ based on LC_ALL >>> and other i18n/l10n conventions. >>> >>> You can of course put whatever garbage you wish into strings that >>> will be stored as keys in an rpmdb, subject to all the usual >>> GIGO conventions distro's wish to inflict upon their customers. >> Okay, my mistake anyways, I was looking into an issue with unicode strings, >> then I specified wrong locale when testing. I notice now that with properly >> specified locale, it accepts unicode characters. >> > > The test is way way feeble, but once the expectation starts, well > there's nothing to do but solve the problem "correctly". > > What is broken -- by design -- is that *.spec recipes have multiple > encodings, not a per-file encoding. And all hell starts to break > loose in *.rpm packages when retrievals using keys pick up a per-key encoding. > > You tell me how to lookup all possible encodings from a database without > specifically tying an encoding to every possible tag. > >> Still though, using '%description -l', descriptions disappears.. :| >> > > C permits octets, not encodings. All possible encodings fit into octets > with NUL terminated strings. The only thing that saves %description > (which doesn't belong in *.rpm packages, another design issue that I don't > feels like arguing about because you somplly will NOT like the answer > of specifying possibly hundreds of properly encoded %description's in > a single *.spec using the full-blown form of the 4-tuple used for > encoding on a per-tag basis. Package metadata will simply explode > for no known purpose. > > And RPM_I18NSTRING_TYPE has been on death row all of this century, > is carried along solely because PLD and a few other distros *still* > insist on inserting translations into *.spec recipes directly. > > A data type that is sometimes an arary, and sometimes a scalar dependent > on the context of interpretation just isn't a useful data type. > > Nor is there any known/modern reason why all possible encodings MUST be > carried in > each and every package header in the year 2011. There's specspo and other > means > of %description et al distribution that are far far superiour to > RPM_I18NSTRING_TYPE pulled > in from *.spec recipes. This was _NOT_ true back in 1998 when > RPM_I18NSTRING_TYPE was devised. Hm, okay, so better obviously needs to be done. For what currently is though, is it supposed to be broken or...? -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES build.c
2011/4/5 Jeff Johnson :
>
> On Apr 5, 2011, at 4:13 PM, Per Øyvind Karlsen wrote:
>
>>>
>> Hm, okay, so better obviously needs to be done.
>>
>
> Have a go at fixing if you wish.
Here's the code that breaks things:
/* Lose the inheirited %description (if present). */
{ HE_t he = memset(alloca(sizeof(*he)), 0, sizeof(*he));
int xx;
he->tag = RPMTAG_DESCRIPTION;
xx = headerGet(pkg->header, he, 0);
he->p.ptr = _free(he->p.ptr);
if (xx && he->t == RPM_STRING_TYPE)
xx = headerDel(pkg->header, he, 0);
}
I assume that what's intended is that headerGet() should set the following:
he->t = RPM_I18NSTRING_TYPE,
but in stead it will always be
he->t = RPM_STRING_TYPE.
So the result is that the only the last description gets added to the package.
Is there a bug in headerGet(), or something about the logic I fail to comprehend
here?
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/macros/ macros.in rpm/ rpmpopt.in
2011/4/10 Jeff Johnson :
> You ought to pull back lib/verify.c (header signature checks re-implemented)
> and rpmdb/hdrfmt.c changes (the sql/json part is done, "works" afaict, I'm
> just waiting
> to see if there's anything else before doing XML spewage the same way
> with EVRD parsing).
k, will (or someone else, please) do!
I'm currently working on finishing up implementing/merging mandriva-specific
parts of /usr/lib/rpm/mandriva/find-{provides,requires} in/with the internal
dependency generator, trying to finish up to prepare for a migration in proper
time to make it for 2011.0, which I wanna finish up first though..
Starting to run out of time left, so any help on remaining issues help would be
appreciated..
I have the bits and pieces to put together the list with details, which I can do
sooner if someone would be willing to take a look at and help out on..
Pinto & Matthew, wanna gimme a lending hand? :o)
If so, I'll get around to providing you with the details right away!
Ps: Matthew is missing from http://rpm5.org/team.php btw. ;)
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/scripts/ Ma...
2011/4/10 Per Ųyvind Karlsen :
> RPM Package Manager, CVS Repository
> http://rpm5.org/cvs/
>
>
> Server: rpm5.org Name: Per Ųyvind Karlsen
> Root: /v/rpm/cvs Email: pkarl...@rpm5.org
> Module: rpm Date: 10-Apr-2011 15:50:29
> Branch: HEAD Handle: 2011041013502801
>
> Added files:
> rpm/scripts check-multiarch-files mkmultiarch
> multiarch-dispatch multiarch-dispatch.h
> multiarch-platform
> Modified files:
> rpm CHANGES
> rpm/macros macros.rpmbuild.in
> rpm/scripts Makefile.am
>
> Log:
> merge multiarch-utils from mandriva.
*phew*
With that, I'm aaalmost done merging, the only remaining script
is the perl dependency extractor, which I want to rewrite a and
improve a bit as well... I hate perl...
I think the perl dependency extractor will be the only mandriva
specific script left now, I think I'll just consider myself satisified
with using it as is for now, then perhaps rewrite later..
At least now it's out there! :)
I'll try merge the remaining macros from rpm-{mandriva,manbo}-setup
into macros/mandriva or the corresponding macro files where
appropriate, almooost done putting it to rest now.
And then there will be cleaning.. *yawn* I need a few minutes break
now..
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/scripts/ Ma...
2011/4/10 Jeff Johnson :
>
> On Apr 10, 2011, at 10:01 AM, Per Øyvind Karlsen wrote:
>
>> 2011/4/10 Per Ųyvind Karlsen :
>>> RPM Package Manager, CVS Repository
>>> http://rpm5.org/cvs/
>>>
>>>
>>> Server: rpm5.org Name: Per Ųyvind Karlsen
>>> Root: /v/rpm/cvs Email: pkarl...@rpm5.org
>>> Module: rpm Date: 10-Apr-2011 15:50:29
>>> Branch: HEAD Handle: 2011041013502801
>>>
>>> Added files:
>>> rpm/scripts check-multiarch-files mkmultiarch
>>> multiarch-dispatch multiarch-dispatch.h
>>> multiarch-platform
>>> Modified files:
>>> rpm CHANGES
>>> rpm/macros macros.rpmbuild.in
>>> rpm/scripts Makefile.am
>>>
>>> Log:
>>> merge multiarch-utils from mandriva.
>> *phew*
>>
>> With that, I'm aaalmost done merging, the only remaining script
>> is the perl dependency extractor, which I want to rewrite a and
>> improve a bit as well... I hate perl...
>>
>
> Careful here: every non-trivial change I've seen to perl(...) *RE's
> ends up breaking something else.
I bet.. :|
The mandriva specific perl(...) dependency generator already seems
a bit awkward and deviating quite a bit already..
>
> You MUST run full distro regression tests to change perl(...)
> dependencies or there will be endless "RPM sux" complaints.
>
> There is rpmdeps --perl that was written to make the regression
> test as painless as possible. 5+ years later, noone but me has ever
> used afaik. But *please* verify regressions against a full distro
> install (this can easily be fit under buildbot "continuous integration"
> too) before muck-a-bout with the existing extraction.
>
> Note also that the perl find requires/provides is written as separate
> scripts. The morern (heh 8+ year old) invocation template is
> -P,--provides
> -R,--requires
> and have *both* (and -C,--conflicts, -O--obsoletes for generality that
> noone has ever attempted afaik) extractions resident in the same script.
>
> Since every bleeping automated helper is implemented/delivered in its own
> peculier
> language and noone (except Ville) is ever really bothering with maintaining
> the patterns taht are in use, having a single script, using -P/-R as above
> is MUSTHAVE. I can't possibly support/maintain scripts in every possible
> language
> within RPM distributed code UNLESS its a single script. And even then I don't
> think every scripts from possible interpreter language belong in rpmbuild
> whatsoever.
>
> There's most definitely a combinatorial failure distributing "fixes", and it
> takes *years* to distribute/deploy even trivial 1-line changes if the scripts
> are distributed with RPM. Enuf already ...
>
>
>> I think the perl dependency extractor will be the only mandriva
>> specific script left now, I think I'll just consider myself satisified
>> with using it as is for now, then perhaps rewrite later..
>>
>
> Cool. You might want to send a list with desired priorities.
> Why you are mucking about with perldeps rewrites after Mandriva
> beta2 is no priority that I understand. Usually rp[mbuild is locked
> into so so so much concrete by "beta2" that any change is impossible.
Yeah, it'll most likely be a candidate for later..
I'm thinking about patching MakeMaker to install the META.yml metadata
generated for all perl packages, then generate dependencies from the
metadata in stead rather as it's (hopefully? according to it's specifications
it "should" be..) cleaner, simpler & more reliable..
But perl people tend to suffer from/inherit some brain damage at one
level or another, so I'm trying to place my expectations realistically
and be prepared for the typical lack of consistency in the perl world..
Quite intrusive and quite a messy world to try muck around in, so we'll
see, it's definitely not something that'll be sane to push at the current
time..
>
>> At least now it's out there! :)
>>
>> I'll try merge the remaining macros from rpm-{mandriva,manbo}-setup
>> into macros/mandriva or the corresponding macro files where
>> appropriate, almooost done putting it to rest now.
>>
>
> Please try to do better wit Mandriva peculier dialect macros. Its
> silly to check-in, and then have t
Re: [CVS] RPM: rpm-5_4: rpm/lib/ rpmds.c
2011/4/10 Hatle, Mark :
> See below inline
>
>
>
> On Apr 9, 2011, at 11:57 PM, "Per Øyvind Karlsen" wrote:
>
>> RPM Package Manager, CVS Repository
>> http://rpm5.org/cvs/
>>
>>
>> Server: rpm5.org Name: Per Øyvind Karlsen
>> Root: /v/rpm/cvs Email: pkarl...@rpm5.org
>> Module: rpm Date: 10-Apr-2011 08:57:24
>> Branch: rpm-5_4 Handle: 2011041006572300
>>
>> Modified files: (Branch: rpm-5_4)
>> rpm/lib rpmds.c
>>
>> Log:
>> filter out some redundant devel(...) dependencies
>>
>> Summary:
>> Revision Changes Path
>> 2.170.2.7 +23 -10 rpm/lib/rpmds.c
>>
>>
>> patch -p0 <<'@@ .'
>> Index: rpm/lib/rpmds.c
>>
>> $ cvs diff -u -r2.170.2.6 -r2.170.2.7 rpmds.c
>> --- rpm/lib/rpmds.c 10 Apr 2011 06:05:58 - 2.170.2.6
>> +++ rpm/lib/rpmds.c 10 Apr 2011 06:57:23 - 2.170.2.7
>> @@ -2904,21 +2904,19 @@
>> if (!devel && s[strlen(s)-1] != ')')
>> (void) stpcpy( stpcpy(tmp, s), "()(64bit)");
>> else {
>> - char *suffix;
>> tmp = stpcpy(tmp, s);
>> - if (devel && (suffix = strstr(t, ".so")))
>> - tmp = suffix;
>> + if (devel)
>> + tmp = strstr(t, ".so");
>> tmp = stpcpy(tmp, "(64bit)");
>> }
>> }else
>> #endif
>> tmp = stpcpy(tmp, s);
>> if (devel) {
>> - char *suffix;
>> - tmp = stpcpy(tmp, s);
>> - if (devel && (suffix = strstr(t, ".so")))
>> + char *suffix = strstr(t, ".so");
>> + if (suffix)
>> tmp = suffix;
>> - (void) stpcpy(tmp, ")");
>> + tmp = stpcpy(tmp, ")");
>> }
>>
>> return t;
>> @@ -3282,8 +3280,16 @@
>> int skipR = (flags & RPMELF_FLAG_SKIPREQUIRES);
>> int lnklen;
>> char path[MAXPATHLEN];
>> + /*
>> + * We filter out these as they come with glibc, making dependencies on
>> + * them rather redundant.
>> + */
>> + const char *filterRequires[] = {"ld-linux", "ld64-linux"
>> "libBrokenLocale.so",
>> + "libanl.so", "libc.so", "libcidn.so", "libcrypt.so", "libdl.so",
>> "libm.so",
>> + "libnsl.so", "libnss_compat.so", "libnss_dns.so", "libnss_files.so",
>> + "libnss_hesiod.so", "libnss_nis.so", "libnss_nisplus.so",
>> "libpthread.so",
>> + "libresolv.so", "librt.so", "libutil.so", "libthread_db.so"};
>> ARGV_t deps = NULL;
>> - size_t nb = strlen(fn);
>>
>
> Filtering out the items below on embedded systems can break things (if I'm
> understanding the code right)... In many embedded systems we use eglibc
> which is configurable, we also some times break up the libc package into many
> small sub packages so that we can only bring in the libraries that are
> actually being used.
Yeah, I did initially do it more minimally, and certainly when splitting up
the libraries in multiple packages, it might easily become a source of grief.
But remember that this is only for devel() dependencies, usually you
don't bother splitting
up the -devel packages that much as you'd might desire to do with the
library packages..
This is an initial implementation ported from bash scripts in mandriva
though, so
there's certainly gonna be some rough edges.. ;)
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
2011/4/10 Hatle, Mark : > > Do you have a pointer or any documentation on how to use these new macros and > helpers? > > Thanks! There's a reference to a page covering it on the mandriva wiki (http://wiki.mandriva.com/en/Policies/Multiarch) stuffed into the macros. It's a bit dated though, and untill the multiarch check during build has been fixed, you won't really be able to easily spot the offenders before you hit them yourself though. I'll probably rewrite the check-multiarch perl script as part of the process fixing it and implementing build termination on positive finding though, so I'll try update and clean up the docs on it afterwards. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
2011/4/10 Jeff Johnson :
>
> On Apr 10, 2011, at 10:30 AM, Hatle, Mark wrote:
>
>>
>> Do you have a pointer or any documentation on how to use these new macros
>> and helpers?
>>
>
> The multiarch macros?
>
> I can tell you what I see:
>
> Instead of ensuring that /usr/include/*.h is independent of arch
> (this was what was done @redhat, took several months of churn-and-burn
> to get the packaging policy to the MANDATORY/ENFORCING level),
> Mandriva has chosen a VPATH-like approach in the build environment,
> where a %{_arch}-mumbo-jumbo is automagically added to rpmbuild
> CFLAGS and there's additional macro magic to rearrange %files.
Yeah, it provides support for working around it easily rather than fixing
it, but once I've fixed the multiarch check, it will be useful for detecting
offenders for fixing (rather than working around by rearranging) as well. :)
>
> Since the whole scheme is based on consistent use of %{_arch}, the
> scheme can/will depend on build system setup in some excruciatingly
> painful ways.
>
> This has just happened in Mandriva Cooker, where %{_arch}
> happened to end-up with "i586" not "i386" (the correct value afaik).
First and only time it has happened, related to me wiping away the
same macros maintained for mandriva specifically from rpm-setup,
ie. a rpm bug. ;p
hehe
>
>
> And for extra speshul painfulness on my own aging box, libcpuinfo
> has decided to put "pentium4" into varous arch-related configgery
> in order to assist me with RPM configgery.
>
The pentium4 macros was already part of cpu-os-macros.tar.gz before
me touching it, otherwise I wouldn't have added it.. :p
>
> You WILL got nutso if you attempt Mandriva multiarch packaging
> policy like this in Poky imho. Cleaner/easier is to patch out
> (or use) @redhat derived packaging instead.
Fixing is of course preferred and often what is being done, but
maintainers doesn't always have the necessary insight and knowledge
to fix this, which makes it convenient to workaround it easily.
Detection during build is useful either direction. :)
>
> But you are not using rpmbuild w Poky so it hardly matters.
>
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
