Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: initng https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 daner964@xxxxxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #128141|0 |1 is obsolete| | ------- Additional Comments From daner964@xxxxxxxxxxxxxx 2006-04-26 03:40 EST ------- Created an attachment (id=128240) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=128240&action=view) initng 0.6.2-1 spec file (In reply to comment #239) > * I think, the old vs. recent SELinux API check should be implemented > in the upstream package Since Dragoran's fix (thanks a lot for that one!) didn't make it into 0.6.2 I'll fix this in the spec for 0.6.3 when released. > * there should be appended a '|| :' to the > > | /usr/sbin/semanage ... > | /sbin/restorecon ... > > calls in %post and %postun, and perhaps '2>/dev/null' too. 'semanage' > is not available for FC4. Fixed. > * %postun is buggy; '/sbin/ldconfig' must be moved into the body: Did I get it right this time? (What was that "-p"?) > | rm -rf %{buildroot} _doc > ~~~~ Fixed. > * the > > | %post > | ... > | exit 0 > > is useless; No idea where that came from. Removed. > * not really wrong, but the '-r' flag can/should be omitted: Well, we might save one cpu cycle or two by removing it ;-) > * when you want a full review, then provide a complete .src.rpm. I'll do that as soon as someone tells me there will be any point with a full review. Judging by Ralf's comment about the package being "way off from being ready for a release", I guess there's no point really yet? > * how mature is the i-files syntax? When scripts will have to be > rewritten for e.g. 0.70, this will stop me from approving it... I'll pass this question on to upstreams ml. The syntax has changed a lot in the past, but it seems to have stabilized lately. > Resp.: when published now, can you guarantee, that > a) package follows upstream releases, and > b) a nightly 'smart update' to a new version will not bring the > system into an unusable state? A is no problem, I'll continue to release as I'm doing now (Only problem might be that I can't reach neither Fedoras build system nor cvs from work because of a corporate firewall, I'll have to do this from home instead). About B, I guess this means that I'll have to solve incompabilities that may arise using scriptlets in the spec file, right? > * when attaching spec files to the ticket, a 'text/plain' type shall > be assigned instead of 'application/octet-stream' Oh. I've always used the "auto-detect", I thought it was smart enough... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.