Re: LSB Package API
On Sat, Jun 21, 2008 at 7:17 PM, Denis Washington [EMAIL PROTECTED] wrote: On Sat, 2008-06-21 at 13:01 -0400, Jeff Johnson wrote: On Jun 21, 2008, at 12:48 PM, Denis Washington wrote: On Sat, 2008-06-21 at 12:27 -0400, Jeff Johnson wrote: On Jun 21, 2008, at 12:05 PM, Denis Washington wrote: What if the transaction fails? register_package() would have returned without error although the registration was unsuccessful then, and all files would already be installed. What if you've added a header, but your daemon exits before successfully computing and adding RPMTAG_SIZE withthe _close_package() method? Got me. Although, if a dummy value (e.g. 0) was added in _register_package(), an unsuccessful _close_package() wouldn't be a harm at all. The header would be complete anyway. Hint: RPMTAG_SIZE simply does not matter. Nor do Vendor: Packager: Description: Summary: and all the other goopiness carried in markup (because its easy to add) and rpmdb Headers. OTOH, RPMTAG_FILESTATES is gonna matter a _LOT_. So will leaving stale locks, and forgetting to attach stderr when your widdle daemon forks. Could you explain what should go in RPM_FILESTATES? It's not listed in the LSB specification. Sorry, but who care on LSB RPM specification aka RPM v3 (other for some useful docu) ? RPM 4.4.2 could not produce it, do you know ? Also , do you know that the LSB RPM spec was bourne only because someone suggest to write some referral on the LSB on MAXIMUN RPM ? Also again do you know that in REDHAT RPM GUIDE someone suggest the author to describe in appendices the RPMV3 package format only for the better docu ? And guess who it is this someone ? R : Jeff Johnson So think more carefully before expressing silly opinions on Jeff Johnson, which authority in the filed is beyond discussion.
Re: LSB Package API
On Sat, Jun 21, 2008 at 7:35 PM, devzero2000 [EMAIL PROTECTED] wrote: On Sat, Jun 21, 2008 at 7:17 PM, Denis Washington [EMAIL PROTECTED] wrote: On Sat, 2008-06-21 at 13:01 -0400, Jeff Johnson wrote: On Jun 21, 2008, at 12:48 PM, Denis Washington wrote: On Sat, 2008-06-21 at 12:27 -0400, Jeff Johnson wrote: On Jun 21, 2008, at 12:05 PM, Denis Washington wrote: What if the transaction fails? register_package() would have returned without error although the registration was unsuccessful then, and all files would already be installed. What if you've added a header, but your daemon exits before successfully computing and adding RPMTAG_SIZE withthe _close_package() method? Got me. Although, if a dummy value (e.g. 0) was added in _register_package(), an unsuccessful _close_package() wouldn't be a harm at all. The header would be complete anyway. Hint: RPMTAG_SIZE simply does not matter. Nor do Vendor: Packager: Description: Summary: and all the other goopiness carried in markup (because its easy to add) and rpmdb Headers. OTOH, RPMTAG_FILESTATES is gonna matter a _LOT_. So will leaving stale locks, and forgetting to attach stderr when your widdle daemon forks. Could you explain what should go in RPM_FILESTATES? It's not listed in the LSB specification. Sorry, but who care on LSB RPM specification aka RPM v3 (other for some useful docu) ? RPM 4.4.2 could not produce it, do you know ? Also , do you know that the LSB RPM spec was bourne only because someone suggest to write some referral on the LSB on MAXIMUN RPM ? Also again do you know that in REDHAT RPM GUIDE someone suggest the author to describe in appendices the RPMV3 package format only for the better docu ? And guess who it is this someone ? R : Jeff Johnson So think more carefully before expressing silly opinions on Jeff Johnson, which authority in the filed is beyond discussion.
Re: LSB Package API
On Sat, Jun 21, 2008 at 8:19 PM, Jeff Johnson [EMAIL PROTECTED] wrote: On Jun 21, 2008, at 1:52 PM, devzero2000 wrote: (aside) It is time for LSB RPM SPEC to move to RPM4 packaging format Indeed. That is the raison d'etre for [EMAIL PROTECTED]. I have not pursued because of zero (yes zero!) interest from vendor's or LSB. So it is likely also for Berlin API zero interest because it is based on LSB RPM specs. Not my problem. I will do a IETF RFC when I get around to it, my forward looking develoment goal is XAR, not RPMv4/LSB, format for packaging. Ok. I already know this and also agreed on the motivation. In the meantime could be useful to have more docu on the rpm4 packaging format, almost for the tags. There is some dubt about the semantic of some of these (RPMTAG_SIZE for example and %ghost and the like discussed recently) Best regards 73 de Jeff __ RPM Package Managerhttp://rpm5.org LSB Communication Listrpm-lsb@rpm5.org
Re: LSB Package API
On Sat, Jun 21, 2008 at 9:46 PM, Jeff Johnson [EMAIL PROTECTED] wrote: On Jun 21, 2008, at 2:45 PM, devzero2000 wrote: Ok. I already know this and also agreed on the motivation. In the meantime could be useful to have more docu on the rpm4 packaging format, almost for the tags. There is some dubt about the semantic of some of these (RPMTAG_SIZE for example and %ghost and the like discussed recently) There is rpm --xml, true WYSIWIG. There is also rpm --yaml, much easier on the eyes. And if one looks carefully, one can also see that RPMTAG_FILENAMES MUST be sorted, and that dependencies SHOULD be sorted (excwpt when vendors/packagers choose to do something different). Without any standard, more doco just adds to the cacophony of packaging wars imho. A true semantic interpretation of how tags should be used/interpreted is largely out of rpm development scope these days. Which is also the basis for my opinion that the opportunity for a LSB Packaging Standard to be useful closed several years ago. There are way too many RPM differences these days for documentation to clarify much of anything. But YMMV, everyone has their own opinion, easily and obviously understood. No. I am wrong and you are right: I am finally aware. What is important it is the rpm5 development no other thing. Best Regards Elia 73 de Jeff __ RPM Package Managerhttp://rpm5.org LSB Communication Listrpm-lsb@rpm5.org
