Hi,
I'm still at rpm 4.5 and I'm looking for a way to replace all i686 packages
with x86_64 ones on a existing system. My rpm is already x86_64 one.
How can I trick rpm to treat i686 and x86_64 packages equally, possibly
without any colors? (so newer x86_64 versions would replace i686
On Mar 4, 2011, at 4:41 PM, Arkadiusz Miskiewicz wrote:
Hi,
I'm still at rpm 4.5 and I'm looking for a way to replace all i686 packages
with x86_64 ones on a existing system. My rpm is already x86_64 one.
There's a way but its been years since I looked at rpm-4.5 ... gimme a day or
two
On Mar 4, 2011, at 4:41 PM, Arkadiusz Miskiewicz wrote:
Hi,
I'm still at rpm 4.5 and I'm looking for a way to replace all i686 packages
with x86_64 ones on a existing system. My rpm is already x86_64 one.
OK, here's the simplest way to achieve a mass replacement of i[3456]86
On Thu, Aug 16, 2007, Robert Scheck wrote:
Evening everybody,
as I'm using RPM 4.5 productively for my system, I've two points:
a) Why are we lacking Berkeley DB 4.6.18? IIRC, there were tries and plans
to do so
b) Can we remove db/docs in 4.5 like in HEAD? On my system this saved
Evening everybody,
as I'm using RPM 4.5 productively for my system, I've two points:
a) Why are we lacking Berkeley DB 4.6.18? IIRC, there were tries and plans
to do so
b) Can we remove db/docs in 4.5 like in HEAD? On my system this saved
about 6 MB at the tarball (8 vs. 14 MB
On Tue, 14 Aug 2007, Jeff Johnson wrote:
First of all, there is no way to set the OS vendor in a path that contains
%{_target_vendor}, eggs come from chickens.
Second, there is no defined and portable way to identify OS vendor from
within a program, chickens come from eggs.
*args* I
On Tue, 14 Aug 2007, Jeff Johnson wrote:
*args* I thought --target bing-bang-boom-bsd defines %{_target_cpu},
%{_target_vendor}, %{_target_os}, %{?_gnu}. But when we're playing chicken
and egg and vice versa here, I now see my mistake and why it can't work.
Good.
One last thing for today:
Evening again,
On Mon, 16 Jul 2007, Jeff Johnson wrote:
The other issue(s) can always be specified by doing
--target CPU-VENDOR-OS-GNU
--macros colon separated list of macros files.
well...I played a bit in configure.ac:
\
+ --POPTdesc=$force operation (short hand for --replacepkgs --
replacefiles --oldpackage on installation)
+
# Choose db interface:
# 0 same as 1
# 1 native db1 interface (e.g. linux glibc libdb1 routines).
# rpm -Uvh rpm-4.5-0.5.i386.rpm rpm-build-4.5-0.5.i386.rpm
I've built rpm-4.5-0.5 packages at
http://wraptastic.org/pub/i386-linux
Aside from adjusting package spec files, I was mainly interested in
finalizing
1) @USRLIBRPM/@VERSION@ aka /usr/lib/rpm/4.5 contents
2) creating a rpm-common package to carry contents like CPU-OS/
macros
Now that I actually have my brain fart under control, db-4.6.18 is
headed
back onto HEAD this weekend.
I can trivially bundle that into rpm-4.5 and expect no problems.
The reason for doing so is to avoid doing so is the
tedious flip-flopping between Berkeley DB versions.
Any reservations
very much doubt
that any of rpm-devel, rpm-python, or rpm-build has any significant
usage case.
Change paths to resurrect rpm-{devel,python,build}?
As rpm-4.5 will be our primary system version, not a parallel
installation, I'm not really too worried about this.
Or feel free to just
allow those traditional packages to be installed as well.
What I'm not sure about is whether its worth the effort. I very
much doubt
that any of rpm-devel, rpm-python, or rpm-build has any significant
usage case.
Change paths to resurrect rpm-{devel,python,build}?
As rpm-4.5 will be our
On Jul 27, 2007, at 2:01 PM, Robert Scheck wrote:
On Fri, 27 Jul 2007, Jeff Johnson wrote:
Any reservations on bundling db-4.6.18 into db-4.5?
Assuming you mean rpm-4.5 rather db-4.5, otherwise this sentence
doesn't
make sense to me.
Yes. Watch for me to type db-2.6 rather than db-4.6
In order to minimize file conflicts with existing vendor packaging,
traditional
rpm configuration has been moved into a rpm-common package containing
what used to be installed in /usr/lib/rpm, while almost everything
specific to
rpm-4.5 has been pushed into /usr/lib/rpm/4.5.
All in order
In order to continue to control rpm versioning, its time to get an
rpm-4.5 release finalized imho.
Most of the changes necessary to install rpm-4.5 side-by-side with
vendor rpm
have already been accomplished in June.
Meanwhile, stabilizing rpm-5.0 builds has been the recent priority. I'm
On Thursday, 26 July 2007, at 14:13:13 (-0400),
Jeff Johnson wrote:
This sounds familiar. Same problem in rpm-4.4.9? Check in the fix
if so please.
Yes, it is. I'll get the fix in as soon as I can.
Oversight. Starting the installplatform SUBSTS patterns with
s,x86_64,x86_64,
On Jul 26, 2007, at 2:05 PM, Michael Jennings wrote:
On Thursday, 26 July 2007, at 11:43:12 (-0400),
Jeff Johnson wrote:
In order to continue to control rpm versioning, its time to get an
rpm-4.5 release finalized imho.
rpm-4.5-0.4 does not build on x86_64 at present. I worked around
On Thu, 26 Jul 2007, Jeff Johnson wrote:
OTOH, preserving existing behavior without reading rpmrc files can be
achieved by merging macro configuration into the default rpm-4.5
configuration.
Read rpmrc files or not?
Not, but we maybe should get an example replacement for redhat-rpm-config
Le lundi 16 juillet 2007, Robert Scheck a écrit :
It's me again,
does somebody know the current state of the support for rpmrc in rpm 4.5?
Jeff ripped it partially out, but for full compatibility with rpm.org we
should at least bring this back for now. When looking to rpm --showrc from
4.5
On Mon, 16 Jul 2007, Olivier Thauvin wrote:
4.4.8 is already no longer using rpmrc. I see no point the back to rpmrc in
4.5, however, I commited recently a hack to give a kind of compatibility for
rpmMachineScrore() functions.
IIRC the point for 4.5 was to be fully compatible with rpm.org,
On Jul 16, 2007, at 5:27 PM, Robert Scheck wrote:
On Mon, 16 Jul 2007, Olivier Thauvin wrote:
4.4.8 is already no longer using rpmrc. I see no point the back to
rpmrc in
4.5, however, I commited recently a hack to give a kind of
compatibility for
rpmMachineScrore() functions.
IIRC the
for
1) rpm-5.0-0.2.src.rpm = HEAD
2) rpm-4.5-0.5.src.rpm = rpm-4_5 for plain brown rpm upgrade
3) rpm5-4.5-0.5.src.rpm = rpm-4_5 for parallel drop-in install
73 de Jeff
__
RPM Package
(DONE).
3) all the helpers in /usr/lib/rpm are going to disappear, as well
as the popt exec glue.
4) the rpm.spec file is going to be largely rewritten.
That should be enough damage for tonight's rpm-4.5-0.4 build. Wish me
luck!
73 de Jeff
-4.5-0.4.src.rpm
Note the following:
1) popt-1.11-1.src.rpm is at the same URL, headed for separate
release this week.
You can either install or not, rpm-4.5-0.4 can use any modern popt
external.
2) The install is into /usr/bin/rpm, not /bin/rpm, so get used to
typing which rpm
or rename
25 matches
Mail list logo
