Jeff Johnson wrote:
The proper fix is to make Obsoletes: persistent like Conflicts:,
with a semantic that any Obsolete:'d package added to a transaction
is automagically discarded (with or without warning with all the usual
enablers/disablers for the warm/fuzzy bikeshed discusssions).
rpm-devel-ow...@rpm5.org wrote:
On Jan 5, 2009, at 12:05 PM, Wichmann, Mats D wrote:
Well, there sure are a lot of current packages out there
with uppercase characters in the name
Bah, uppercase, who needs it?!? Use UTF-128 encoding instead!
Heh...
Otherwise noted. And I'll add
rpm-devel-ow...@rpm5.org wrote:
This off-hand comment regarding Mandriva DUDF - CUDF
translation needed by the Mancoosi project reminds me
of a design mis-feature in RPM:
- package names: they should match the naming convention we
discussed, i.e., only lowercase characters, numbers, dashes
Tim Mooney wrote:
In regard to: rpm3 package still exist, devzero2000 said (at 4:53pm
on Jun...:
rpm -qi TIVsm-API
Name: TIVsm-APIRelocations: /opt
Version : 5.3.0 Vendor: IBM
Release : 0 Build
Jeff Johnson wrote:
I know that PCRE and POSIX are functionally equivalent.
But can the interconversion between PCRE - POSIX regexes be
automated?
I'd love a general have it your own way RE interconversion
rather than have to choose either PCRE or POSIX regex dialect.
rpm got enuf
As discusssed before rpm-4.4.7 release, I have negative interest
in supporting vendors like Sun and IBM who refuse to upgrade
the version of rpm they use for packaging:
don't worry, if the rumblings I hear are right future
java versions will come with an all-in-one (that is, for
all operating
[EMAIL PROTECTED] wrote:
On Sun, Jul 29, 2007, Jeff Johnson wrote:
The dbenv is stateful, and per-instance. Why are you copying __db*
files around, they are useless, as you have seen, out of context.
Well, in OpenPKG since years we've created a database under
DESTDIRprefix/RPM/DB/ and
I'm ecstatic that ia64 is not in the list above. For some
extremely twisted hacks in rpm one should do
grep ia64 lib/*.c
it's just the /emul stuff, afacit, and that's a
twisted concept to begin with. linux-ia64 made a
particular choice a long time ago. Does anybody
else actually use
Without automated testing, and without binary, de facto demonstrable
testing, I think adoption of rpm-5.0 will take quite a while.
So what can we do to automate testing? Given the ability
to pull down a fresh binary rpm, or build from a fresh
tarball, what constitutes a functional/regression
[EMAIL PROTECTED] wrote:
On Saturday 30 June 2007 12:02, Jeff Johnson [EMAIL PROTECTED] wrote:
OK/ fsync before close, todo++. Thanks for the info, xfs is a mystery
to me.
If you want to know any specific things about XFS then ask me.
I'm currently working for SGI in a group that is
[EMAIL PROTECTED] wrote:
The LSB packaging cabal has decided that what 3rd party ISV's really
want is the ability to run their own installers on rpm managed
systems.
jeez, you always have to put things in such positive terms,
doncha? the LSB packaging people are just responding to
what
[EMAIL PROTECTED] wrote:
On Jun 6, 2007, at 9:29 AM, Wichmann, Mats D wrote:
Hey, we all said anything but cvs during the earlier discussion,
but here we still are...
2 weeks, not 2 years, later.
For 2 weeks, progress is rather astonishing. I'm sure we can all
agree on that.
maybe I
12 matches
Mail list logo
