portindex ignores (filters out) unchanged port
Clemens Lang
cal at macports.org
Sun Dec 27 15:11:28 PST 2015
Hello,
On Sun, Dec 27, 2015 at 11:10:45PM +0100, René J.V. Bertin wrote:
> 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
So are you saying you have a Portfile kde/kate/Portfile that provides
the kate port, and a Portfile kf5/kate/Portfile that provides kf5-kate?
In that cause you should actually pay attention to your lint warnings
and fix your directory naming first. If the Portfile provides kf5-kate,
it should be in a kf5-kate directory.
> 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.
Two ports with the same name in a single port tree are unsupported.
Don't do that.
> 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?)
When portindex reindexes a port, it will also reindex all its subports.
There is no easy way to determine whether a change in the Portfile did
affect a subport or not, but I agree that the detection of whether a
Portfile was actually modified or not could be improved (it's currently
based on a global timestamp across all Portfiles, adding a hash would
mean adding an additional piece of metadata for each port).
> 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.
The decision whether to reindex a port is based on the mtime of the
existing port index and the mtime of the Portfile.
> 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
They're Tcl files, basically. base/src/port/portindex.tcl has the code
that generates them. Look at the trunk version of it, because I
refactored it a while ago to make it more readable. The code you're
looking for are lines 107 and 108, where a port index entry is
potentially re-used without re-executing the Portfile if there already
is an entry for it in the PortIndex.quick file. Note that there is no
way to figure out which port a Portfile is going to provide without
fully running it (which comes with the full runtime overhead and is thus
not an option), so we are using the directory name to do this lookup. If
you're violating the rule of having a category/portname/Portfile provide
the "portname" port, this will not work for you, and you're wrong in
doing this. Note that this will work correctly even for subports, iff
you port provides "portname" in addition to any number of subports.
--
Clemens
More information about the macports-dev
mailing list