Bugzilla Bug 225759

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 an attachment (id=156445) [edit]
ca-certs_portable-find.patch

Here it is, nice and pretty, patch with the correct find -perm

(From update of attachment 156445 [edit])
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 [edit] [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