LEDE Table of Packages: Good or bad?

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.

[quote="stangri, post:67, topic:123, full:true"]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![/quote]Thanks. :smiley:

[quote]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.[/quote]AFAIK most packages don't have a README, that's an issue that should be fixed imho, but there are more pressing needs atm.

I can always add a link later if needed, the lists will be fully rebuilt from scratch to update them every week or so anyway.

That means, with each release we would get additional 4.000 new dataentries, with only minor differences to the previous dataentries? Not a good idea.

You see the response time with 4000 dataentries. It will not get faster with additional 4000. And another additional 4000... and another....

Why not make lede-release a multi-value field? Instead of adding new dataentries, just update the existing ones. This would avoid the proliferation of dataentries.

Changes in dataentries:
OLD: LEDE releases_lede-release : snapshot # Only one release per package
NEW: LEDE releases_lede-release s : snapshot # List all releases where this package is available

The rest of the dataentries shows the latest status (excluding trunk/snapshot).

For now, I found a solution that keeps the Dependencies field free of indeed ugly and lengthy "-snapshot".
For making this work in both, dataentries and datatables, please change the dataentries to:

Dependencies_pkg-dependencies

Re-added link to package-page.
Heretical question: Who will add those 4000 package-pages?-)
If 10 package pages would be created per day, it would take more than a year to have all missing pages together.... just mentioning.

Oh, which ones do you miss? Which devices are missing categories?

Example url(s) please.

PS. FFS, I can't even post a link without some smart features on this forum!?

[quote="tmomas, post:69, topic:123, full:true"]Why not make lede-release a multi-value field? Instead of adding new dataentries, just update the existing ones. This would avoid the proliferation of dataentries.
...
The rest of the dataentries shows the latest status (excluding trunk/snapshot).[/quote]No, that's dropping potentially useful information. I don't like this. I understand that we need a trade-off but losing information is NOT acceptable.

I prefer my idea of separating dataentries in folders by release and of course keeping them in different ToPs, so the data plugin running each ToP will only have to deal with the packages in a single LEDE release.

This will mean people won't be able to see/search LEDE snapshot packages from the ToP of LEDE Release 1, but I think this isn't really necessary for users (it might be cooler for mantainers, but it's not anywhere near crucial)

Ah yeah. this will waste like 4-5 MiB of storage space in the server for each release though. :scream:

[quote]For now, I found a solution that keeps the Dependencies field free of indeed ugly and lengthy "-snapshot".[/quote]Ok, but the above should also solve the issue right?

[quote]Heretical question: Who will add those 4000 package-pages?-)[/quote]A script can write a basic page just to not have the red link (which is ugly), but adding actual tutorials/content is open to anyone that feels like it. (I can actually add an optional module to the current script that can be activated on command or if it does not find a package page *.txt already to keep this automated for the future)

Not unlike device pages, anyway. There is a ton of dummy device pages over on OpenWRT wiki isn't it? They must stay though as if someone needs to write something about that device must have the proper place to do so.

[quote] Oh, which ones do you miss? Which devices are missing categories?
[/quote]I'm talking of my script, and of packages lists. There are quite a few packages that were supposed to have 3 categories, my mistake, already fixed in the script.

[quote="stangri, post:71, topic:123, full:true"]PS. FFS, I can't even post a link without some smart features on this forum!?[/quote]Discourse is good for us, Discourse is good for you, Discourse is good for everyone.

Don't resist the future, embrace Discourse's user-empowering smart features! :stuck_out_tongue:

Take a look at https://wiki.lede-project.org/pkgdata/adblock-snapshot
Good idea? Bad idea? Please let me know your thoughts.

[quote="tmomas, post:74, topic:123, full:true"]Take a look at https://wiki.lede-project.org/pkgdata/adblock-snapshot
Good idea? Bad idea? Please let me know your thoughts.[/quote]Can you change the font of that box? It's nice to have the readme there, but the font is killing me.

Which information would be dropped?
Why is it important to have the dropped information?
Who would use the table of packages to answer which question?
Or in other words: What would be the usecase of the ToH?

Sorry for asking that much questions, I just want to figure out what we are doing for which user and what the requirements are.

Exactly. And all that missing information that is displayed in those dummy pages doesn't give a good picture. We should avoid having 4000 half done package-pages, and rather prefer 100 well done ones that we then link to.

How would you like to have it?

Looks great man! Not sure if you can fix the extra line breaks before description and architectures, that'd be awesome!

Also, I believe there're free frameworks to display formatted github markdown content, if you could use that sometime in the future for showing README.md, that'd be outstanding.

[quote="tmomas, post:77, topic:123, full:true"]How would you like to have it?[/quote]See how Github shows it here

Please send a pull request to the maintainer of the gh plugin.
https://www.dokuwiki.org/plugin:gh