R-commonmark Macports page duplicates test deps as lib deps

[barracuda156]

R-commonmark page on Macports duplicates test deps as lib deps: ​https://ports.macports.org/port/R-commonmark/details Portfile does not do that: ​https://github.com/macports/macports-ports/blob/master/R/R-commonmark/Portfile They should in fact only be test deps: ​https://cran.r-project.org/web/packages/commonmark/index.html

Where is this coming from?

[ryandesign (Ryan Carsten Schmidt)]

Maybe there is a bug in the way that the ​MacPorts web app imports its port information.

[ryandesign (Ryan Carsten Schmidt)]

They used to be lib dependencies before they were changed to test dependencies. Maybe the web app is forgetting to clear out previously-declared dependencies when updating a port.

[barracuda156]

Replying to ryandesign:

They used to be lib dependencies before they were changed to test dependencies. Maybe the web app is forgetting to clear out previously-declared dependencies when updating a port.

I thought about that, but then I would have at least revbumped the port; turned out, version was updated.

[ryandesign (Ryan Carsten Schmidt)]

The web app maintains a database with information about ports and their dependencies and other metadata. Periodically a script runs that updates that database with whatever has changed since the last time it ran. Imagine if the script runs pseudocode like this:

for each port that was changed
    for each type of dependency (lib, test, build, etc.)
        if the port has that type of dependency
            add or update that dependency data for that port

In other words, prior to the commit I mentioned, information about R-commonmark 1.8.0 was in the database, including that it had three lib dependencies. After that commit, the script noticed that R-commonmark was updated to 1.9.0. The script noticed that it has test dependencies so it added the test dependency information to the database. The script noticed that the port did not have lib dependencies, so it didn't do anything, erroneously leaving the previous lib dependencies in the database.

I don't know if that's how the web app's code works, but it's a guess about what could have happened, based on the apparent state of the database today from what we can see on the web site.

[barracuda156]

Replying to ryandesign:

I don't know if that's how the web app's code works, but it's a guess about what could have happened, based on the apparent state of the database today from what we can see on the web site.

Makes sense. Well, not a big deal after all, it is just the website and the issue seems incidental.

[ryandesign (Ryan Carsten Schmidt)]

The information on the web site seems to match the port now. Maybe the web site just hadn't completely updated before.

[barracuda156]

Replying to ryandesign:

The information on the web site seems to match the port now. Maybe the web site just hadn't completely updated before.

Yes, can be closed.