...or, if XS (arch-specific) bits were added to perl-DBIx-Class (which isn't terribly unlikely), all of a sudden it would be using directories under /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi, not /usr/lib/perl5/vendor_perl/5.10.0.
.. Also hosing directory ownership. (noarch/arch changes like this are rare, but hardly uncommon.)
Another, perhaps clearer way of saying this is: perl-DBIx-Class-EncodedColumn will require perl-DBIx-Class through the virtual perl provide of perl(DBIx::Class); yet requiring perl(DBIx::Class) does not guarantee that any particular directory under Perl lib paths (@INC) will be created and owned.
Perl requires are managed through the perl(*) set of virtual provides. Depending on a certain perl(*) provide to own specific directories is risky at best, and a mess towards its worst. The only sane, clean and consistent way to deal with this is for each perl-* package to own everything it provides.