portindex ignores (filters out) unchanged port

[Clemens Lang]

On Mon, Dec 28, 2015 at 12:35:17AM +0100, René J.V. Bertin wrote:
> On Monday December 28 2015 00:11:28 Clemens Lang wrote:
> 
> > and fix your directory naming first. If the Portfile provides
> > kf5-kate, it should be in a kf5-kate directory.
> 
> I'd just as well avoid having redundant information in the paths;
> kf5-kate is already in the kf5 category/tree, so its portdir doesn't
> need to have that additional tag. Also saves typing.

This isn't redundant information, as you can see from the portindex
code. That's also the reason why there is a lint check for it.

"Doctor, it hurts when I do that…" Stop doing it then!


> > Two ports with the same name in a single port tree are unsupported.
> > Don't do that.
> 
> But I don't ... the ports are called kate and kf5-kate.

But their directory name is the same, which is unsupported. The category
is irrelevant in this decision.


> Of course, I only reflected on the fact that adding subports to a
> Portfile causes it to be reindexed every time.

No, it doesn't. That only happens if your port isn't in a directory
named after its main port.


> That's beginning to increase the indexing time of my portree
> noticeably; I have a few Portfiles with a rather large number of
> subports (the KF5 Frameworks metaport, but also the port with all of
> Calligra's translations).

There is no easy way to avoid re-indexing all subports of a Portfile,
when the Portfile has changed. See the python graveyard port for an
example of where the re-index times get massive due to subports. :/

> > 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
> 
> Is that actually needed if you determined the port name(s) it provided
> once and associate those with a sufficiently strong hash? I'd say it
> isn't; as long as mtime and hash are unchanged the name shouldn't have
> changed either.

Yes, as long as mtime and hash are not changed, the port names should
stay the same (excluding changes to portgroups, but those already
require revbumps of all ports including them anyway on such changes).

The reason why we are currently not doing this is that we do not have
per-port metadata like mtime or a hash (or a list of ports it provides)
stored in (or somewhere related to) the portindex. Once that capability
was there, we could add a check like this.


> If you agree with this that might actually make looking at improving
> the index a bit more appealing to me :)

I'm not sure whether I like relaxing the rule of naming a directory the
same as the port it provides, because that decision enforces structure
in our ports tree. If we remove that requirement, port names become
arbitrary.

-- 
Clemens