sigh, I uploaded a batch of files and the media manager interface shows them correctly, problem is, they don't seem to show in the Site Map, nor in the table.
I think the wiki is placing them in a dedicated folder for uploaded things, not in the /pkgdata folder.
Waaaaah, the wiki is frustrating me. 
Will upload a zip for you to load them sometime in the future.
D'oh!
Sorry, I didn't think of the media manager uploading everything to the /media directory 
I moved the dataentries now to the correct location in /pkgdata.
Observations:
[quote="tmomas, post:49, topic:123, full:true"]Sorry, I didn't think of the media manager uploading everything to the /media directory [/quote]On the bright side, you can leave txt or whatever other extension enabled in the long term too.
On the dark side, you will need to move packages manually around a few times while I'm testing.
[quote] - Categories: Need to be separated by ','
[quote]- Maintainer: If you put a '|' (pipe) in front of the name, the name will automatically link to /contact[/quote]Not sure about how useful that would be, the recommended way to contact the mantainer is to open an issue/bugreport ticket anyway.
[quote]- LEDE release: Should we call it "snapshot" instead of "trunk"? This would fit better to https://downloads.lede-project.org/snapshots/ [/quote]I'd say no. That is trunk, built as snapshots daily or something.
Btw, I've found a way to shorten links. you must use the _wiki tag in the field name, then you can use wiki syntax to make the links as normal (also any other wiki syntax will work). They say here to not abuse this as it has a performance impact.
my test in the wiki here
EDIT: hmm, no it seems to show the text anyway in the table.
EDIT2: yes, it should work but you need to define that field as _wiki in the table too https://www.dokuwiki.org/plugin:struct:type_wiki
Just tested this with 6in4 entry, it shows as short link in the wiki too.
EDIT3: it seems I managed to screw up the database somehow, now there is a broken 6in4 entry I can't delete (I deleted the 6in4 entry text file and also tried to re-create the table, the borked entry persists). 
[quote="bobafetthotmail, post:50, topic:123"]
Should we call it "snapshot" instead of "trunk"? This would fit better to https://downloads.lede-project.org/snapshots/
I'd say no. That is trunk, built as snapshots daily or something.
[/quote]Well, to add some confusion to the discussion, "trunk" was actually main branch in the old SVN system, while now there is the "master" in git. Right now all old-timers still understand "trunk", but after a while it may start sounding weird.
A couple of comments to that table. You might need to adjust table column widths. Right now some look strange. E,g,
Adjust Luci to display max. 26 characters (= luci's own version string).
Longer version strings are cut to: "first 21c" + ".." + "last 3c"
The last 3 chars are used to preserve the possible PKG_REVISION string.
E.g. 'opkg' has only hash+PKG_REVISION, so using only start of the string
might not be optimal.
.
Ok, thanks for the clarification.
I think a better/modern naming would be "Nightly" then, as it is what most other projects use for similar "built-from-latest-est-est-development-sources-built-daily" releases.
This trunk-> Nightlies change should happen everywhere for consistency, but afaik that's only wiki or LEDE main site, so we can alter that fine.
[quote="hnyman, post:52, topic:123, full:true"]* version column is too wide.
[/quote]Yeah, also package name (same reason) will shorten both up as requested.
Consider that in most cases the actual table shown will have less fields
I would advise against it, for the performance reasons mentioned.
I tried this once with the ToH on a rpi2, and man, this was noticeable!
Sure, the machine the wiki is running on is no rpi2, but still, with 1000+ packages, this must have a huge impact on performance.
O - oh! You break it, you pay it... and that's going to be expensive!
Just joking, fixed it already 
[quote="tmomas, post:55, topic:123, full:true"]I would advise against it, for the performance reasons mentioned.
I tried this once with the ToH on a rpi2, and man, this was noticeable!
Sure, the machine the wiki is running on is no rpi2, but still, with 1000+ packages, this must have a huge impact on performance.[/quote]Can we still do a test with the current server and my package lists? (sent you a email with a tar.gz)
I mean, with all due respect (as it isn't meant for high-performance), but the raspi2's CPU is obsolete laggy garbage and its storage access speeds are subpar.
tgz uploaded, searchindex update is running.
Note: Please create the links without spaces.
[[ https://github.com/openwrt/packages/issues | Bug reports ]] -> [[https://github.com/openwrt/packages/issues|Bug reports]]
Links with spaces will be shown as "wanted pages" in the wiki, which is not what we want.
For future updates: Please upload it via the media manager, always with the same name. I've got a script in place that takes care of the rest.
lol, fixed.
The page is still showing the old entries through (in addition to the new ones), even if the text files were removed.
Also, yes, it takes quite a bit to load, I'll have to do more test tomorrow.
For future updates: Please upload it via the media manager, always with
the same name. I've got a script in place that takes care of the rest.
ok will do.
Does https://wiki.lede-project.org/packages/start work for you?
It times out here...
EDIT #1: Filtered now for LuCI to make the page load.
Seems this amount of data is a bit much for the plugin 
EDIT #2: I removed "Architectures" from the datatable and put it on a separate page -> https://wiki.lede-project.org/packages/top
Filtered = less data to display = less time to load the page. This makes the page somewhat usable, although is takes a considerable amount of time for the page to load for e.g. "net" with >1000 packages.
If you look at the package categories on https://wiki.lede-project.org/packages/start, you will see some with count=1
These should be cleaned up and sorted in existing categories.
Example: LuCI(1) -> luci(826)
All "boost-" packages:
License : Boost Software License <http
-> "<http" to be removed
Made https://wiki.lede-project.org/packages/start now usable by adding "max : 100" to the datatable definition, which shows only the first 100 matching results, and then leads to a "Next page" link at the bottom of the table.
[quote="tmomas, post:60, topic:123, full:true"]
Does https://wiki.lede-project.org/packages/start work for you?
It times out here...[/quote]it took like a minute, it worked but it was not really acceptable.
Considering the goal (see answer below) it's good enough.
[quote]Filtered = less data to display = less time to load the page. This makes the page somewhat usable, although is takes a considerable amount of time for the page to load for e.g. "net" with >1000 packages.[/quote]Yes, the general idea was to have most packages appear in highly filtered table views (i.e. showing all "net" isn't filtered enough as it is a major category, like "util"), while the only view with no filter would be the "search the ToP" view, and there we can leave a relatively low limit on shown fields (I've currently put 50 and it loads well).
Example: LuCI(1) -> luci(826)
and
-> "<http" to be removed
Yeah, there are also some packages without maintainer (not from base feed as there I've written "LEDE team" there), and probably some other weirdness we didn't yet notice too.
Now that they are indexed I can look at them with a decent GUI (I'm not a fan of opening 4300 text files manually), will then modify the script for the next round.
What was the reason for adding "-snapshot" to the dataentries' name?
Without this, column "Dependencies" could link to the dataentries of the dependencies.
BTW: I removed the link from "Name", but we could also leave this in and have a link to a package-page. Not sure what to show there, though.
[quote="tmomas, post:65, topic:123, full:true"]What was the reason for adding "-snapshot" to the dataentries' name?[/quote]because they are packages of release "snapshot", when LEDE makes a release, there will be new dataentries with "-release-name" too.
This allows to keep packages with same (package) name but different LEDE releases, as I said the Stable LEDE releases will likely lag behind in version, may have different dependencies or whatever from the LEDE snapshot (or from other stable LEDE releases).
[quote]Without this, column "Dependencies" could link to the dataentries of the dependencies.[/quote]Hmm, I see. I could modify the name there to have the -snapshot too, but it would look bad, adding wiki links manually would add performance hit so probably no.
What about making different folders into /pkgdata for each release? then the packages in each folder would not need to have a different name, but maybe (depending on dataplugin's limitations) it might not be possible to show them together anymore.
Not a major issue imho, most people will look at the packages available in a specific release, not through all LEDE releases.
[quote]BTW: I removed the link from "Name", but we could also leave this in and have a link to a package-page. Not sure what to show there, though.[/quote]Leave the link to package-page. That would be the place to keep/link all the information/tutorials/whatever about that specific package.
EDIT: btw, it seems the script didn't load all categories, there should be much more than this.
This is an exciting new development, ability to know which packages are included/available for a particular platform before installing LEDE is a great feature!
One comment tho, maybe you should consider linking to package's README in github if it's something which would be more convenient for package creators to use rather than submitting package description/how-to separately.
If it's not something that package maintainers typically do, just ignore this.