On Sunday December 27 2015 12:28:30 Daniel J. Luke wrote: > On Dec 27, 2015, at 3:44 AM, René J.V. Bertin <[email protected]> wrote: > > Any ideas? > > read the portindex code? debug what is going on on your system?
I might do that one day, if no one has the answer handy. I had a look at the PortIndex files, and while `portindex` claimed it reused the existing kf5-kate entry, I actually found 2 entries for kate. So I tried a hunch: rather than having kde/kate/Portfile -> port:kate kf5/kate/Portfile -> port:kf5-kate I renamed kf5/kate to kf5/kate5 to avoid having 2 port directories with identical names. That defeats the purpose of organising the port repository using the filesystem, but that's another topic. With this new naming (ditto for the kompare ports), ports no longer disappear, but see below. > > > Why does portindex reprocess portfiles with subports, btw? Is it because it > > was too complicated to determine nothing changed in those files? (Storing a > > hash for a port's portfile should do the trick, no?) > > sounds like you have an idea for an improvement? You should write up a patch > and try to get it included. Actually, it turns out the reason is less straightforward. After renaming the port directories, the ports are now treated on each portindex run. It seems as if portindex will only skip a known portfile if it lives in a directory that matches the port name. And that explains why subports are scanned time and time again: they evidently don't live in a directory with the same name. Improving this is something I could give a try, but I'd need to have a good understanding of how port indices are supposed to work. They're ascii files, so I doubt one can just add some information to them and assume the consuming code will continue to work R. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
