[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: What is this error?



On Thu, 2003-06-05 at 01:53, Jeff Johnson wrote:
> On Thu, Jun 05, 2003 at 01:04:00AM +0300, Panu Matilainen wrote:
> > 
> > Making sense in long term is not what I'm asking for with a i586 box :)
> 
> So buy yourself a present or use a down rev, non-concurrent version
> of rpm. You can't have everything. ;-)
> 
> > The thing is I've little interest to buy i686 hardware to get NPTL just
> > to get concurrent access as long as the i586 does it's job.
> > 
> > a) Does rpm-4.1.1 support concurrent access to the extent that rpm-4.1
> > on RH 8.0 does, without NPTL support?
> 
> Yes. What is lacking, however, is unified thread and process locks,
> that requires futexes. Since multi-threaded rpm implementations are
> just a gleam in my eye ATM, you won't care a whit.

Ok thanks, this is basically what I wanted (apart from buying myself a
present of a firewall box more powerful than I need :) to know.

> 
> > ..or..
> > b) Is i586 capable of NPTL -> if I recompile glibc for i586 arch do I
> > magically get NPTL support on that too? I know plain old i386 can't
> > support NPTL but whether i586 can I dunno. (ok this isn't really rpm
> > turf so if you don't know .. well I dont blame you :)
> 
> Yes, capable afaik, with the caveat that secret i686 specific kernel voo-doo
> glue may currently be mixed into the futex implementation. Ask some kernel
> guru, I'm just a NPTL consumer.
> 
> > 
> > P.S. To make perhaps a bit of sense to why I care about this at all:
> > I've got a script doing basically 'rpm -V <pgk1> <pkg2>...' to find
> > modified configuration files while apt holds the rpmdb lock and since
> > the script worked fine on my other box I was somewhat surprised it
> > didn't on the i586 box.
> 
> Again, you don't really need concurrent locks at all, if you're willing
> to live with the very, very, rare chance of a segfault.
> 
> In fact, there is no locking for root in rpm-4.0.3 and rpm-4.0.4, and
> it's not exactly like rpm crashed and burned.
> 
> Also in fact, apt is known to have added the keyword "private" to rpmdb config,
> which disables all locking. Again, apt didn't exactly crash and burn afaik.

It's not apt who did that (though I did ask some questions here a while
ago regarding "private") but certain vendor(s) who shipped rpm
configured with "private" by default. Anyway they seem to have survived
it... Probably the easiest way to deal with it, since in this case I'm
100% sure nobody's really writing anything to rpmdb, just apt having
write lock on it to protect apt from things changing underneath and
another doing read-only query.

> 
> BTW, what's really, really silly is for apt to link rpm, and then reinvoke
> /bin/rpm with most every check disabled. Either always invoke /bin/rpm, or
> always link, mixed mode is just asking for trouble, basically because
> you have insufficient control over deadlocking even if concurrent access
> is enabled.

I never understood why it's done that way either and really dislike it
every bit as much as you do. However the problem of "does this package
have modified configuration files" has more to do with apt not providing
that information natively than the implementation with rpmlib+/bin/rpm
(the script I'm talking about is internal apt Lua-script with access to
most of apt's package information), I think it's more
a) deb's don't contain such information -> apt wasn't designed to deal
with it -> apt-rpm has to live within the common denominator realm
b) nobody saw such feature necessary even if deb's do provide that info 
..or whatever. That's not your problem :) Thanks for clarifying a couple
of unclear issues.


	- Panu -




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []