Re: Which distros are using rpm5
On Tue, Jan 15, 2013 at 9:45 AM, Ibrahim Yurtseven arastirmaci...@aol.de wrote: Hey ho, Which distros are using rpm5 except Mandriva? Maybe Mageia, the Mandriva fork? No. Mageia was not interested some time ago. https://www.mageia.org/pipermail/mageia-dev/20110302/002867.html. Rosalab for example use rpm5 http://www.rosalab.com/. Jbj can tell you more. Best -- Ibrahim Arastirmacilar Yurtseven The web is what you make of it __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides issue with re-packaging a complex product (endeca)
On Sat, Jan 5, 2013 at 10:02 PM, Mykel Alvis mal...@restorationhardware.com wrote: devzero2000 over on the rpm-users list suggested %define _use_internal_dependency_generator 0 My self, devzero2000 (Elia Pinto) is part of the rpm5 team, thanks to jeff. Since the request was for rpm 4.8 I preferred answer you on the rpm mailing list. Best __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides issue with re-packaging a complex product (endeca)
On Sat, Jan 5, 2013 at 10:15 PM, Jeffrey Johnson n3...@me.com wrote: On Jan 5, 2013, at 4:02 PM, Mykel Alvis wrote: devzero2000 over on the rpm-users list suggested %define _use_internal_dependency_generator 0 This did exactly what I needed. Yes but … there are profound changes to the *.rpm package format that are coupled to setting %_use_internal_dependency_generator to 0. That macro was _NEVER_ designed to be flipped around on a per-package basis by package monkeys. Yes, but apparently autoreq to 0 doesn't work on the sharelib deps on rpm 4.8 (@rpm.org). I have seen ocaml package setting %_use_internal_dependency_generator to 0 before ocaml deps was included in rpm. http://markmail.org/message/hdwyn3ys675psmcz But perhaps i am missing something, probably. Best regards __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Fwd: [Puppet Users] Managing Puppet modules as RPMs
-- Forwarded message -- From: devzero2000 pinto.e...@gmail.com Date: Sun, 27 May 2012 08:14:53 +0200 Subject: Fwd: [Puppet Users] Managing Puppet modules as RPMs To: rpm-u...@rpm5.org Fyi. Despite some FUD the use case is interesting for devops. Best regards -- Forwarded message -- From: devzero2000 pinto.e...@gmail.com Date: Sun, 27 May 2012 08:10:54 +0200 Subject: Re: [Puppet Users] Managing Puppet modules as RPMs To: puppet-us...@googlegroups.com Sorry for the top posting. Imnsho, rpm had always permitted to have multiple package version if they not conflict, in fact the usual case is the kernel. Anyway your question is most rpm related: so if you like i suggest you to ask to a rpm mailing list. Best regards 2012/5/27, Anthony Shortland anth...@dtosolutions.com: We're using Puppet as part of a broader toolchain that relies on delivering software for deployment using sets of Yum-based RPM packages. We've setup system, role and application specific Yum repositories on an environment-by-environment basis that ensure that the required set of RPM versions flow appropriately (e.g. from development to QA to staging and hence to production). In this spirit we're packaging our Puppet modules as sets of RPMs too so the correct versions of the system, role and application specific modules flow along with everything else. The problem arises when you consider the conflict that arises between the natural use of Yum-based RPM installation and the Puppet master's module delivery mechanisms. Puppet allows modulepath to be set on an environment-by-environment basis, of course, thus supporting delivering different versions of modules from a master managing several environments. The restriction lies with Yum/RPM's inability to allow multiple versions of the same (relocatable) package to be installed on the same system (even good old System V packages could do that!). I'm looking for workarounds that aren't too egregious to either system! Here are the ideas we've come up with so far: Hack the RPM package names to include a version discriminator (e.g. packageV1-1.0-noarch.rpm rather than package-1.0-noarch.rpm) to allow them all to be installed on Puppet master Use Yum/RPM to install the modules directly on the client systems and find a way to restrict the Puppet master to managing the manifests rather than attempting to install the modules too. Is the second method workable? It seems to be a blend between agent and apply modes. We don't want to use apply mode since we really value using the master (even supplemented with Hiera) to act as the resource model provider to deliver configuration attributes to the agents as well as act as the node provider for Rundeck (used for distributed orchestration) using the Puppet/Rundeck plug-in (which doesn't seem to be environment aware - but that's another story!). We'd appreciate any comments and feedback on this. Thanks, Anthony. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Inviato dal mio dispositivo mobile -- Inviato dal mio dispositivo mobile -- Inviato dal mio dispositivo mobile __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpm5 compilation on rhel6.
On Wed, Feb 15, 2012 at 9:59 PM, Maruthi Devulapalli maruthi.devulapa...@axa-tech.com wrote: Hi All, ** ** Need your help with this, ** ** make[3]: Entering directory xmlFreeParserCtxt' /tmp/rpm/rpm-5.3.5/misc/.libs/librpmmisc.so: undefined reference to xmlCreatePushParserCtxt' /tmp/rpm/rpm-5.3.5/misc/.libs/librpmmisc.so: undefined reference to /tmp/rpm/rpm-5.3.5/rpmconstant' make[2]: *** [all] Error 2 make[2]: Leaving directory /tmp/rpm/rpm-5.3.5' make: *** [all] Error 2 ** ** ** ** configured with ./configure --with-openssl=/usr/local/ssl/ --with-db=/usr/include/db51 Should be sufficient ./devtool checkout ./devtool harwich ** ** ** ** Best Regards Maruthi Devulapalli NASD – Unix 201-743-6585 ** ** This email originates from AXA Technology Services UK Limited (reg. no. 1854856) which has its registered office at 5 Old Broad Street, London EC2N 1AD, England. This message and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this in error, you should not disseminate or copy this email. Please notify the sender immediately and delete this email from your system. Please also note that any opinions presented in this email are solely those of the author and do not necessarily represent those of The AXA UK Plc Group. Email transmission cannot be guaranteed to be secure, or error free as information could be intercepted, corrupted, lost, destroyed, late in arriving or incomplete as a result of the transmission process. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. Finally, the recipient should check this email and any attachments for viruses. The AXA UK Plc Group accept no liability for any damage caused by any virus transmitted by this email.
Re: How to detect rpm post scriptlet failure
On Thu, Oct 13, 2011 at 9:15 AM, Levon Poghosyan deimusmeis...@gmail.comwrote:
Thanks for the reply.
The situation is following. I've got an application which installs bunch of
rpm packages.
Some of those packages have post scriptlet failing, so I need to
know/figure out which are failing.
Those packages are many, so I think it wont be the best solution to modify
all off them to store their post install scriptlet execution status in /var,
any other solution for this case ?
Regards,
Levon
FWIW, there is a related bugzilla for @rpm.org
https://bugzilla.redhat.com/show_bug.cgi?id=569930
(rpm exit 0 always on scriptlet execution)
In other package management system exists state as half installed or so.
But
here are two issue relevant i think :
- Should be failing script relevant or not (see the bugzilla for a
discussion on this, in
particular for %post) ? @rpm.org choose to exit always with 0
- How should applications or users know that there is some errors ?
In any case @rpm5.org add the scriplets exit code to the header registrated
in a rpmdb and also to the source rpm (for detecting a wrong use of
--short-circuit).
rpm -q --yaml arbitrarytags
(snip)
.
Scriptstates:
- 0
- 0
- 0
- 131072 %post exit code : this number mean exit 0
you can also use
rpm -q --qf '[%{SCRIPTSTATES}]\n' arbitrarytag
000*131072*
^
|
Hope this help
Best Regards
here are two issues relevant (imho
Should failing scripts be permitted?
and a obscurely related general design issue
How should applications and users and ... be notified of errors?
On 12 October 2011 21:22, Jeff Johnson n3npq@gmail.com wrote:
On Oct 12, 2011, at 11:38 AM, Levon Poghosyan wrote:
Hello,
How can I detect if the execution of post scriptlet of the rpm package
failed ?
The simple answer here is:
You don't.
All I mean by that is that the %post script needs to be written robustly
so that the exit code is always 0.
If you need/want to tell whether some specific operation worked,
then write a test after rpm has run for that specific operation.
Another approach would be to have the %post script register its
state somewhere in /var so that you can easily test whether the script
worked or not.
I've generated the and rpm package which has a test command lalala in
post install section. So during the installation it prints out information
that command lalala was not found but the installation is still successful.
How do I identify this failure from post install section.
A %post scriptlet (the only difference between script and scriptlet is
that a
scriplet is macro expanded and may eventually have some envvar's
prepended instead of having RPM add to the environ directly) is
just a script.
SO use test(1) to test for existence and executability, and write that
into
the %post section directly.
Because a %post is part of a package install state machine, the script
SHOULD return 0 for all but catasstrophic faiulures.
There are side-effects of returning failure from %post, the most important
of which is that on an upgrade, the erase will be skipped if/when the
install fails.
Please note I'm not interested in failure in other places, I just need
to be informed in post install scriptlet failed.
Personal;ly, I'd just write the %post script to write 1 line into
/var/lib/application/state
with the message
The %post script succeeded
or (on failure)
The %post script failed.
I'd have to know more about what is implied by a %post success/failure
in order to suggest some other approach.
hth
73 de Jeff
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org
--
Address Yerevan, Baghramyan 70/75
Re: How to detect rpm post scriptlet failure
On Thu, Oct 13, 2011 at 12:13 PM, Levon Poghosyan
deimusmeis...@gmail.comwrote:
It seems to be there is no chance to do this in rpm 4.8.1, am I right ?
I can not answer for @rpm.org, I certainly can not propose a patch for @
rpm.org.
But i know that this correlated ticket
https://bugzilla.redhat.com/show_bug.cgi?id=569930
was openened formally to redhat. But it does not seem to have been taken into
account so far.
Best Regards
On 13 October 2011 11:04, devzero2000 pinto.e...@gmail.com wrote:
On Thu, Oct 13, 2011 at 9:15 AM, Levon Poghosyan deimusmeis...@gmail.com
wrote:
Thanks for the reply.
The situation is following. I've got an application which installs bunch
of rpm packages.
Some of those packages have post scriptlet failing, so I need to
know/figure out which are failing.
Those packages are many, so I think it wont be the best solution to
modify all off them to store their post install scriptlet execution status
in /var, any other solution for this case ?
Regards,
Levon
FWIW, there is a related bugzilla for @rpm.org
https://bugzilla.redhat.com/show_bug.cgi?id=569930
(rpm exit 0 always on scriptlet execution)
In other package management system exists state as half installed or so.
But
here are two issue relevant i think :
- Should be failing script relevant or not (see the bugzilla for a
discussion on this, in
particular for %post) ? @rpm.org choose to exit always with 0
- How should applications or users know that there is some errors ?
In any case @rpm5.org add the scriplets exit code to the header
registrated in a rpmdb and also to the source rpm (for detecting a wrong use
of --short-circuit).
rpm -q --yaml arbitrarytags
(snip)
.
Scriptstates:
- 0
- 0
- 0
- 131072 %post exit code : this number mean exit
0
you can also use
rpm -q --qf '[%{SCRIPTSTATES}]\n' arbitrarytag
000*131072*
^
|
Hope this help
Best Regards
here are two issues relevant (imho
Should failing scripts be permitted?
and a obscurely related general design issue
How should applications and users and ... be notified of errors?
On 12 October 2011 21:22, Jeff Johnson n3npq@gmail.com wrote:
On Oct 12, 2011, at 11:38 AM, Levon Poghosyan wrote:
Hello,
How can I detect if the execution of post scriptlet of the rpm package
failed ?
The simple answer here is:
You don't.
All I mean by that is that the %post script needs to be written
robustly
so that the exit code is always 0.
If you need/want to tell whether some specific operation worked,
then write a test after rpm has run for that specific operation.
Another approach would be to have the %post script register its
state somewhere in /var so that you can easily test whether the script
worked or not.
I've generated the and rpm package which has a test command lalala
in post install section. So during the installation it prints out
information that command lalala was not found but the installation is still
successful.
How do I identify this failure from post install section.
A %post scriptlet (the only difference between script and scriptlet is
that a
scriplet is macro expanded and may eventually have some envvar's
prepended instead of having RPM add to the environ directly) is
just a script.
SO use test(1) to test for existence and executability, and write that
into
the %post section directly.
Because a %post is part of a package install state machine, the script
SHOULD return 0 for all but catasstrophic faiulures.
There are side-effects of returning failure from %post, the most
important
of which is that on an upgrade, the erase will be skipped if/when the
install fails.
Please note I'm not interested in failure in other places, I just need
to be informed in post install scriptlet failed.
Personal;ly, I'd just write the %post script to write 1 line into
/var/lib/application/state
with the message
The %post script succeeded
or (on failure)
The %post script failed.
I'd have to know more about what is implied by a %post success/failure
in order to suggest some other approach.
hth
73 de Jeff
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org
--
Address Yerevan, Baghramyan 70/75
--
Address Yerevan, Baghramyan 70/75
Re: rpm install and folder creation
On Sun, Sep 4, 2011 at 4:47 PM, Jeff Johnson n3...@mac.com wrote: On Jun 4, 2010, at 2:55 AM, Belal Salem wrote: Hi there! I issued the same issue before, when installing some packages, the RPM package manager doesn't create the required folders and ask for the folders as unresolved dependencies, although those folders are part of the package being installed. Its part of the package which is confusing. There are two meanings for part of the package: 1) directory components as part of file paths 2) directory explicitly listed in rpm -qpl *.rpm If its not explicitly in the file manifest, its not part of the package and you *will* see what you are reporting. Recompiling RPM with the options: --disable-dirname-and-symlink-deps didn't solve the problem, anyway through that?! I'm not the person to fix --disable-dirname-and-symlink-deps. My fix will be to rip out the Have it your own way! functionality that isn't working and remove the --disable-dirname-and-symlink-deps in order to simplify RPM's build and clarify supported functionality. I see no future in carrying around functionality that doesn't work as it should and is vendor supported by others here @rpm5.org. I will rip out the option if it isn't fixed by someone else @rpm5.org this month. No, it is right that i rip out the option tomorrow. I have introduced it, it is equivalent to vendor supported - i am pretty sure - but probably don't work as it should. But if so there should be a spec with directory-symlink broken deps that does not work even in Mandriva for example. I would love to see this spec, possibly for tomorrow. Perhaps ark linux and mandriva could be find useful. Thanks. Best Regards PS FWIW, this is description of this disabler https://blueprints.launchpad.net/rpm/+spec/rpm-split-vendor-config-in-autofu. https://blueprints.launchpad.net/rpm/+spec/rpm-split-vendor-config-in-autofu goog_702910032The idea was to simplify bootstrapping distributions that do not use rpm5 as a package manager or that are broken from a QA POW such as RHEL5: in short for simplify rpm5 adoption in first place. I am sure someone @ rpm5.org had used patch - not upstream - similar for RHEL5. My memory is not so bad, i have seen this in a mail some year ago. The old dog can have good memory, yes. The idea was 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Creating an RPM to install a daemon
On Thu, Oct 28, 2010 at 5:10 PM, Joe Flowers joe.flow...@nofreewill.comwrote: Hello Everyone, I am trying to create an RPM that will install a daemon correctly, but I'm not sure if or where I should put the command: chkconfig --level 345 /etc/rc.d/mydaemon on Should this line go somewhere in the Makefile (like the install section), or should it go in the RPM .spec file somewhere? Is there some other command I should use rather than this external chkconfig program? If you want to use the fedora way to do packaging http://fedoraproject.org/wiki/Packaging/SysVInitScript https://fedoraproject.org/wiki/Packaging/ScriptletSnippets http://fedoraproject.org/wiki/Packaging/Guidelines the standard way is (example squid with some my comment) .. Requires(post): /sbin/chkconfig Requires(preun): /sbin/service /sbin/chkconfig Requires(postun): /sbin/service . .. %post /sbin/chkconfig --add squid %preun #last removal if [ $1 = 0 ] ; then service squid stop /dev/null 21 rm -f /var/log/squid/* /sbin/chkconfig --del squid fi %postun #restart the service if it was already running, in update only if [ $1 -ge 1 ] ; then service squid condrestart /dev/null 21 fi If you were curious of why there are if condition based on the number of package installed ($1) that it's because in update RPM performs the following sequence of actions (the install-before-remove sequence tipical of RPM) * Run%pre of new package * Install new files * Run% post of new package * Run% preun of old package * Delete any old files not overwritten by newer ones * Run% postun of old package best regards Thanks! Joe --- __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Building a 32-bit RPM on a 64-bit machine?
It depends if your package use autoconf,automake,libtool or not. BTW, the standard way is setarch i386 rpmbuild --target=i386 --rebuild pippo.src.rpm, or better use an automated tool that do this as mock, for examplehttp://fedoraproject.org/wiki/Projects/Mock. http://fedoraproject.org/wiki/Projects/Mock Regards On Fri, Oct 29, 2010 at 3:07 PM, Joe Flowers joe.flow...@nofreewill.comwrote: Hello again, I would like to be able to create a 32-bit RPM (with no 64-bit library dependencies) on a 64-bit machine. I have a 64-bit, SuSE development machine, and I would like to create an RPM on this 64-bit machine that will install 32-bit software on a 32-bit SuSE machine. Any ideas on the correct way for me to proceed? Thanks for any and all guidance! Joe P.S. Thanks very much Jeff for the answer to my Creating an RPM to install a daemon question. -- __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Change Version Name
On Mon, Mar 1, 2010 at 1:29 PM, Manoj Palhade mpalh...@googlemail.comwrote: Dear RPM Team, I have requirement to change RPM Version Name. In AC_INIT of configure.ac is the best place IMHO and after rebuild. Regards
high performance computing, HA and RPM5
High performance computing systems are very popular for some time. The problems of Hign Avalibility computer systems are common in the same way. The question is how a package management system as rpm5 can address the problems of such environments. I have not found any reference to such issues, in general systems package management system, as rpm5. Overall this system are starting from the a simple assumption : a single system and a single db metadata (dpkg have not a real db however). But this assumption is wrong on a system of HPC: in general, the applications are installed in the absence of a true package but are installed manuallu on a file or network distributed systems: NFS, GFS2, Luster for example. The problem, from my point of view, is that applications are not installed using a package system like rpm5 but installed manually: anyone thinks at this point it is sufficient to create a virtual package with only requires for issue like update conflict or the like and it is difficult to prove the opposite: Why should I install the same package separately on multiple nodes where the package is the same and it is installed on the same place (on a distributed or network filesystem). I have the opinion that a distributed system requires a rpm5 metadata distributed database and the fact that rpm5 includes a relational (or a sort of it in the latest incarnation of berkeley db) database system like the model is certainly an advantage - this what Iof a advocate of the relational model as Chris Date tell about this issue, last time i have checked. On the pragmatic view, specifically, assuming the same (as patch version) 100 nodes should be possible to extend / var / lib / rpm / Packages with a shared rpm5 Packages (extending _db_path for example ) on which should be able to act as a fragment of Packages (an Union of Packages if you like ) and if this it is unavailable, well no problem. The preceding are only a personal opinion. There are other opinions? I have perhaps missing something ? Thanks in Advance __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: high performance computing, HA and RPM5
On Mon, Dec 7, 2009 at 4:19 PM, Jeff Johnson n3...@mac.com wrote: On Dec 7, 2009, at 9:37 AM, devzero2000 wrote: On Mon, Dec 7, 2009 at 2:55 PM, Jeff Johnson n3...@mac.com wrote: On Dec 7, 2009, at 7:47 AM, devzero2000 wrote: High performance computing systems are very popular for some time. The problems of Hign Avalibility computer systems are common in the same way. The question is how a package management system as rpm5 can address the problems of such environments. I have not found any reference to such issues, in general systems package management system, as rpm5. Overall this system are starting from the a simple assumption : a single system and a single db metadata (dpkg have not a real db however). But this assumption is wrong on a system of HPC: in general, the applications are installed in the absence of a true package but are installed manuallu on a file or network distributed systems: NFS, GFS2, Luster for example. The problem, from my point of view, is that applications are not installed using a package system like rpm5 but installed manually: anyone thinks at this point it is sufficient to create a virtual package with only requires for issue like update conflict or the like and it is difficult to prove the opposite: Why should I install the same package separately on multiple nodes where the package is the same and it is installed on the same place (on a distributed or network filesystem). I have the opinion that a distributed system requires a rpm5 metadata distributed database and the fact that rpm5 includes a relational (or a sort of it in the latest incarnation of berkeley db) database system like the model is certainly an advantage - this what Iof a advocate of the relational model as Chris Date tell about this issue, last time i have checked. On the pragmatic view, specifically, assuming the same (as patch version) 100 nodes should be possible to extend / var / lib / rpm / Packages with a shared rpm5 Packages (extending _db_path for example ) on which should be able to act as a fragment of Packages (an Union of Packages if you like ) and if this it is unavailable, well no problem. The preceding are only a personal opinion. There are other opinions? I have perhaps missing something ? HPC is usually focussed on scaling, installing identical software on many nodes efficiently. Distributing system images with modest per-node customization tends to be simpler than per-node package management. Package management is useful for constructing the system images. But PM cannot compete with system images for installation scaling to multiple nodes. First of all, thanks for your reply. But i disagree on this point : it would be like saying that cloning is more useful than using conga and puppet (or kickstart FWIW) and here I disagree. Well let's decompose the above statements into pieces to identify where we disagree. Distributing system images ... tends to be simpler ... and cloning. From a purely implementation POV, a package manager will always have more overhead than blasting content onto physical media. The overhead introduced by kernels and file systems and libraries and applications is eliminated if physical images are distributed. ... modest per-node customization ... PM cannot compete and using conga/puppet/kickstart package != configuration management is likely the crux of the disagreement. I don't believe RPM is very good at configuration management, which is better handled by kickstart or puppet or conga or Augeas. Most attempts at CM in *.rpm are through scriptlets, with known deficiencies. I would claim that scriptlets are the single largest cause of upgrade failures today. Whether single largest or one of the largest is hardly worth discussing. So I suspect we differ in package vs. configuration management assumptions. Not like. I am pretty sure we agreed. Doing upgrades of multiple nodes is typically done by creating a new system image, and then undertaking a reinstallation of the new system image. This isn't as efficient as upgrading a package on a per-node basis because new system images will contain redundant already installed software. Its very hard to beat a reboot of a new system image located on a distributed file system for KISS efficiency. Tracking what system image is installed back to a specific PM database that describes the installed software within the system image could be done with a wrapper on rpm to choose 1-of-N rpmdb's to perform detailed queries re files in the system image. But a flat file manifest of what packages were installed in a system image is likely sufficient for most purposes as well. But THIS make it useless or worse, the role of a package managemement system, let it call call RPM5 or other. Are you sure ? Not sure about anything. What I described is based on an assumption
Re: Attempting to compile rpm5 for RH Linux EL5
On Fri, Sep 18, 2009 at 6:41 PM, Jeff Johnson n3...@mac.com wrote:
On Sep 18, 2009, at 12:11 PM, Saravanan Shanmugham (sarvi) wrote:
Separating the symbol files and into their own package is definitely in
the plans.
Well, packaging detached debugging symbols (and source code so
that line numbers can be displayed) was done in RPM like 5 years
ago and is already widely deployed.
iirc the first time debuginfo was deployed was with REDHAT 9
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/release-notes/x86/
This is the original proposal
https://bugzilla.redhat.com/show_bug.cgi?id=67760
You really should look at what is implemented.
Note that from a RPM packaging POV, the existing -debuginfo scheme
is all very feeble and hacky and horendously fragile and obscure.
I mostly agree. IIRC, it depends also by a not upstream patch to gdb and
work only with the GCC compiler collection. Or perhaps also i don't have
undestood it well.
(aside) In your opinion I right or wrong that if a package don't have
debugging symbol the rpmbuild fail if the packager don't define %define
debug_package %{nil} - or use the obsure hack to exit in %install . But
perhaps i digress...
So don't take my comments as criticism, I'd *LOVE* to see a better
packaging framework for detached debugging symbols in RPM.
The question is the turnaround time between someone posting a traceback
on the web and a backend system translating the traceback with symbols.
If end-to-end turnaround efficiency is your goal, you need to
look carefully at how traceback information can be accurately
associated with the components involved. Extracting executables/libraries
from *.rpm is just a very teensy part of a much larger problem.
One option is to have a filesystem where all the files have been
extracted and ready for translation. But can cost additional diskspace
which can add up in the long run.
That's basically what is in a -debuginfo package, files under
/usr/src/debug/* include source and detached debugging symbols.
If the RPMs are archived, the system would need to identify the RPMS
involved in traceback, download, extract them, do the translation, then
discard the extracted stuff.
This could takes some time to do, specially if you have to download the
whole RPM, and if you had to uncompress/untar each RPM in its entirity.
From RPM, tar.gz or CPIO, this can be expenseive. As I understand it you
need to unzip and untar the file, piping it to a filter to get the
file(s) you want.
XAR format maintains an index, that allows you to go to and extract a
specific file, and the individual files are compressed, as I understand
it, meaning the ones of interest can be extracted, which can be more
efficient.
Again, speed or overhead of archive extraction is hardly an issue when
everything
necessary for debugging is _ALREADY_ extracted into a -debuginfo package.
At this point, I am just trying to understand/measure that cost
impact/tradeoff, and was looking to try these features.
Look closely at tools/debugedit.c and scripts/find-debuginfo.sh. Those
two files are what is used to automate producing -debuginfo packages.
Some ref are also here
https://fedoraproject.org/wiki/Packaging/Debuginfo
I'd suggest grabbing some -debuginfo *.rpm files and examining. This
command makes it quite easy to see what is in a -debuginfo package
rpm -qp --yaml foo-debuginfo*.rpm
hth
73 de Jeff
Sarvi
-Original Message-
From: rpm-users-ow...@rpm5.org [mailto:rpm-users-ow...@rpm5.org] On
Behalf Of Jeff Johnson
Sent: Friday, September 18, 2009 5:34 AM
To: rpm-users@rpm5.org
Subject: Re: Attempting to compile rpm5 for RH Linux EL5
On Sep 18, 2009, at 2:04 AM, Saravanan Shanmugham (sarvi) wrote:
Thanks. I was able to get it compiled and installed.
I am proposing the use of RPM5 for package management internally. One
point of interest to me in RPM5 is the use of XAR format, and more
specifically the option of being able to extract specific files from
within the XAR archive without having to untar/extracting everything.
Atleast that's what the xar wiki page claims.
You can extract specific files from any archive format, including
cpio/tar/xar, rather easily.
We need a way to be able to extract specific executables and libraries
from a specific version of the build, from its archived RPMs, on
demand, to help decode a crash or traceback.
So you would seem to want debugging symbols. What is more commonly done
is to split the symbols from the executable/library and put into a
separate -debuginfo package.
GDB then loads the detached symbols.
So far, I haven't been able to figure out the RPM5 option or XAR
option that allows me to do extract a specific file or list of files.
For cpio payloads it starts with
rpm2cpio foo*.rpm | cpio -itv
to display the files in a payload. Then one adds logic (described in
man cpio) to select which files you want.
Re: Spaces in filenames in a spec file???
On Mon, Jul 13, 2009 at 1:44 AM, Michael Lasevichmisdirec...@lasevich.net wrote: Ok, my root has these files and directories (all empty): -rw-r--r-- 1 root root 0 Jul 12 19:18 File With Spaces drwxr-xr-x 2 root root 4096 Jul 12 19:12 dir With Spaces drwxr-xr-x 2 root root 4096 Jul 12 19:12 dirWithoutSpaces -rw-r--r-- 1 root root 0 Jul 12 19:18 fileWithoutSpaces Genrated spec file is: === Name: vj_space_tester Version: 1.2 Release: 090712_1925 License: None Group: None BuildRoot: /data/yum/factory/space_tester/root AutoReqProv: no Summary: No Summary BuildArch: noarch Requires: vj_base # Finished header %description space_tester # Description done #%prep #%build #%install #%post %files %defattr (755,root,root) %dir Sorry for the delay. But the problem is this (a typo perhaps) statement - %dir -- Dropped this and with or without quoting in /dirWithoutSpaces rpmbuild work as expected in rpm 4.4.2-9.el5 Perhaps you wanted really create a directory with a blank inside? So do you have to write %dir / . And it works also regards __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Spaces in filenames in a spec file???
On Fri, Jul 10, 2009 at 9:25 PM, Michael Lasevich mich...@lasevich.netwrote: I need to package an rpm that contains files with spaces in them. Sounds like it should be easy, but I am completely stuck. I tried the backslash escape, I tried putting the filename in double quotes - nothing seems to work. I ran into this a number of times over the years and normally I would just rename the file, but in this particular case that is not an option. I can't believe that rpm cannot handle this, which means there has to be an escape scheme that I am missing here. Google turned up zilch. Any help would be appreciated. If it matters, I am using rpm-4.4.2.3-9.el5 SIA. Not problem at all to answer BUT perhaps you have written to the wrong mailing list ? This is RPM5 : some years of development have passed from rpm 4.4.2.x.y.z. Just for curiosity. Thanks. -Michael __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: autoconf - rpm
On Sun, May 24, 2009 at 4:28 AM, Jeff Johnson n3...@mac.com wrote: On May 23, 2009, at 9:39 PM, barcaroller wrote: Ah, I see what you are asking now. As you know, the GNU autotools do (at least) three things: - they check for dependencies and other stuff (configure) I'm unaware of any fully automated reliable tool for generating BuildRequires: (the RPM dependencies). There are many subtle issues with naming and versions that are tricky to automate reliably. I agreed. BTW, exists a new project that want to automate this sort of thing http://et.redhat.com/~rjones/auto-buildrequires/http://et.redhat.com/%7Erjones/auto-buildrequires/ Regards Elia
Re: RPM 5.0.2 released
Thanks
But it seems there is some access permission
For example
http://wraptastic.org/pub/i386-linux/RPMS/rpm-5.0.2-1.i386.rpm
On Feb 6, 2008 12:42 AM, Jeff Johnson [EMAIL PROTECTED] wrote:
On Feb 5, 2008, at 5:17 PM, devzero2000 wrote:
Good !!1
But the rpm, where is ?
Again, rpm5.org is vendor neutral, and so releases tar balls, not *.rpm
packages.
Meanwhile, the rpm.spec.in file vontained in rpm-5.0.2.tar.gz is
mostly functional.
All I needed to fix was this minor problem:
--- rpm.spec.in 22 Jan 2008 21:52:44 - 2.450
+++ rpm.spec.in 5 Feb 2008 23:41:31 -
@@ -274,6 +274,7 @@ gzip -9n apidocs/man/man*/* || :
rm -rf .%{_mandir}/pl/man8/rpmcache.8*
rm -rf .%{_mandir}/pl/man8/rpmgraph.8*
rm -rf .%{_mandir}/{fr,ko}
+ rm -rf .%{_mandir}/man1/xar.1*
rm -rf .%{_bindir}/xar
rm -rf .%{_includedir}/xar
rm -rf .%{_libdir}/libxar*
I've used the spec file in the rpm-5.0.2.tar.gz release to build
binary packages
on a Fedora 9 platform that are available at
http://wraptastic.org/pub/i386-linux/RPMS/
hth
73 de Jeff
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org
