When running update-ca-certificates I get this.... # update-ca-certificates Updating certificates in /root/gentoo/etc/ssl/certs....done. Running hooks in /etc/ca-certificates/update.d..../root/gentoo/usr/sbin/update-ca-certificates: line 96: run-parts: command not found done. Doing 'equery belongs run-parts' on an x86 box and I get.... [ Searching for file(s) run-parts in *... ] sys-apps/debianutils-2.28.2 (/bin/run-parts) Reproducible: Always
fixed in cvs.
sorry but... RDEPEND.badindev 2 app-misc/ca-certificates/ca-certificates-20080514-r1.ebuild: ~sparc-fbsd(default-bsd/fbsd/6.2/sparc) ['sys-apps/debianutils'] app-misc/ca-certificates/ca-certificates-20080514-r1.ebuild: ~x86-fbsd(default-bsd/fbsd/6.2/x86) ['sys-apps/debianutils'] this makes it uninstallable on all the bsd. There must be a better fix.
aballier: just keyword debianutils on fbsd?
(In reply to comment #3) > aballier: just keyword debianutils on fbsd? > 09:28 <@aballier> loki_val: main point is, i think, we dont want *debian*utils on bsd ;) [...] 09:31 <@The_Paya> loki_val: the preferred way in that case I think it would be to replace run-parts with something else. 09:31 <@The_Paya> kinda silly to depend on a package for just a command that runs scripts. 09:31 <@aballier> find ? maybe something to investigate more
I agree this does not work for bsd at all. debianutils depends on coreutils which cant be used either.
I agree this does not work for bsd at all. debianutils depends on coreutils or mktemp which we don't need either provided by sys-freebsd/freebsd-ubin.
your analysis is incorrect. ca-certificates needs mktemp ... the DEPEND there is to just ease upgrade paths. you also shouldnt have keyworded the package in question in the first place if you didnt test it ... ca-certificates will not work if you dont have a "run-parts" binary. since i doubt the bsd's provide it, it means you need debianutils installed.
(In reply to comment #7) > you also shouldnt have keyworded the package in question in the first place if > you didnt test it ... ca-certificates will not work if you dont have a > "run-parts" binary. since i doubt the bsd's provide it, it means you need > debianutils installed. > In this case run-parts it's not used to /execute/ any scripts, it's used to save the typing of: find ${DIR} -maxdepth 1 -perm -0700 -type f It just *prints* (uses --test) the files that are executable on the hooksdir directory (which is empty in every gentoo I checked) and then the update script goes on to "eval ${them}" not even using run-parts again for that purpose. This could be easily solved by replacing run-parts with that find command, depend on another package for just *that* feels kinda silly.
those commands are not equivalent. if you want to post a correct patch, feel free.
Created attachment 156445 [details, diff] ca-certs_portable-find.patch Here it is, nice and pretty, patch with the correct find -perm
Comment on attachment 156445 [details, diff] ca-certs_portable-find.patch please review the run-parts man page. it isnt a simple find. it includes filters in file names.
(In reply to comment #11) > (From update of attachment 156445 [details, diff] [edit]) > please review the run-parts man page. it isnt a simple find. it includes > filters in file names. > From the manpage: If the --lsbsysinit option is *not* given then the names must consist entirely of upper and lower case letters, digits, underscores, hyphens and periods. However, the name must not begin with a period. Adding \! -name "\.*" filters the names beginning with a period. Unless I'm missing some other character that may go into a script under /etc/ca-certificates/update.d ...
the breadth of valid characters that make up valid unix names is much more vast than what the manpage says run-parts looks for ... just look at your keyboard
perhaps we could just be lazy and keyword debianutils if we could have installkernel and mkboot installed under kernel_linux ?
binding both of those binaries to kernel_linux sounds pretty reasonable, so if you want to commit that change, go for it
(In reply to comment #15) > binding both of those binaries to kernel_linux sounds pretty reasonable, so if > you want to commit that change, go for it > all good now, only sparc-fbsd left which i'll do as soon as the changes will have propagated to the rsync mirrors for the test box
thanks
