Provide a "CLI Essentials" SPK?

[cytec]

Already mentioned here: #2071 with all those CLI Tool PR's coming in lately that'll may be a good thing to do in the near future...

Personally i don't care if we provide a single SPK for each of them or just combine them all into one single SPK but i think it's a lot cleaner for the users and may be not as confusing for some of them (expecting that some may not know that this are cli tools and reporting "errors")

Here is the list from the PR above as well as the new ones that came after that PR:

• nano SPK Published
• vim SPK Published
• htop SPK Published
• ldd
• bc PR pending
• sudo
• nice (contained in Busybox?)
• screen
• less PR pending
• detox PR pending
• ncdu PR pending
• fdupes PR pending

New:

• lsscsi PR pending
• nmon PR pending
• davfs2 PR pending

there may be others but that's all i currently remember any thoughts @SynoCommunity/developers

EDIT: maybe we could even add a busybox build and depend on that SPK for other SPK`s that need to use some of the busybox functions (a lot of python only apps use python's busybox already)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Dr-Bean]

I do want to point out that there's a difference between CLI-based software that is worth its own package, and CLI 'tools' that don't warrant a separate package (with a grey area in between).
You feel the same, because you haven't added all the CLI-based packages by quite a margin ;)

There's a grey area where I'm not 100% convinced either way, but I'd say this is my current pov based on your list (it'd be longer if we actually added all CLI-based packages):
Separate package:

• nano
• vim

Combined:

• ldd
• bc
• sudo (DB: available in DSM6, legacy only. I'd probably skip this myself. Does it actually run on Busybox?)
• nice (contained in Busybox?) (DB: yep, not sure it's worth it. It's generally useful when added to running daemons, but it should be part of the package then)
• screen
• less
• detox
• ncdu
• fdupes
• htop (DB: Available in DSM5.1+, so legacy only. I can see this being removed at some point)

As for busybox itself: I'm not sure I can put it into words properly, but I really dislike having a base package that is required to be installed for a very specific set of operations that relate to installing/running a package (create users/start-stop-daemon/nice). Of course, you can argue that the same applies to, say, Python or Git, but for some reason, that feels different to me.

[cytec]

the busybox part was just a thought that popped up my head as i wrote this issue, but thinking about it you may be right... python does it but i get your point on how that feels different... and compiling busybox isn't that worse at all ;)

i didn't add all CLI based Applications as for several reasons:

1. As you said there are some that deserve a own SPK (nano, vim)
2. stuff like x264 also provides a CLI Interface but i don't think that'll be used often
3. Those i've listed feel like the "most usefull" or "most used" cli apps maybe adding unrar and stuff like that too... even if there currently is no SPK for that...
4. For now i limited the list on Packages that already have a SPK and/or a PR... Packages that are only in cross aren't considered (ex: unrar which seems pretty "essential" too)

[bru7us]

Bundling tools that are only related by the fact that they are CLI-only doesn't really feel right either.
The dream that comes to mind for me when thinking about CLI tools is just a "package manager" SPK... (Can we search/pull/install SPKs from the CLI yet?).

We would still build separate SPKs for each tool, but provide a package on which they would all depend. This new base package could provide the ability to add or remove CLI-based SPKs from the command line (or why not all SPKs?).

Another option is to drop the SPK layer for separate tools and have the package manager SPK just list/pull binaries for all of the supported tools/apps, but then someone would need to build that solution and also host it with a different front end than the repo we currently have.

[Dr-Bean]

Lets see if we're on the same page here. From my point of view, the reason to consider doing this is that it allows us to provide software that we would otherwise not create a separate package for, e.g. due to too limited scope (small userbase expected), more-'tool'-than-software kind of idea.

I don't think we should consider it a catch-all or depend upon it from other packages, or add something that already exists (isn't unrar provided by Synology already, for example?)
With that as a starting point, the list in my previous comment is probably too long already. There's a grey area, and I can see certain entries on the list go either way.

As for the package manager SPK: I don't see that as an option myself. For one, it goes beyond merely combining software into one package: It sounds more like working around DSM's Package Center by creating a separate package manager. Something similar exists already: optware/ipkg/etc.

[bru7us]

I agree that the package manager would be a hack, and also a reinvention of the wheel.

I think the biggest issue at hand here is how would we define that line of what makes 'the cut' to have its own standalone SPK - because everyone has different needs. I don't like installing a bundle of say.. 20 tools because I need 'less', but if that was the only option, I'd do it.

Comments in #2071 also suggest splitting out into some logical groups (like build-essential in apt), which could be a middle ground between the overhead of an SPK each and a huge dumping bucket for any tool that doesn't deserve an SPK.
Having a choice can often muddy the water too, defining how each bundle should be associated. So having a single big bucket has a couple of pro points there in reduction of management overhead.

[cytec]

well the main cause for me to open this issue was that after every update i was tired that i have to put /opt/bin/ back in path again so screen and some of the other tools work again... also im not really a fan of installing 20 seperate SPK's... if they are big enough to deserve their own (like nano) ok but i don't think that ldd, bc and less are that "big" from the "what the community needs" site of view.

I also like the suggestion to split that stuff in logical groups (if we come to a point where that makes sense)...

[Dr-Bean]

Ok. The logical groups sounds alright, but it only works if you have enough software to be split up in the first place ;)
The other problem with it is that it's hard to go back on a choice once we release a package. From a user perspective, you get this: "I installed package X because of tool Y, and now Y is gone, what gives?"

Anyway, let's see if that works. Still going off the original list:

• We have bc, ldd, less and screen. I can see the first three being combined, but screen just looks like an outlier here. What do you think?
• detox, fdupes could presumably be combined into some type of CLI file manipulation package, together with cross/coreutils (currently no package for that that I'm aware of, not even sure of the added value, but it's there)
• ncdu could be combined with testdisk into a CLI disk management type of package. If htop were still needed, it could go into a CLI monitoring tools...

[biyiklioglu]

We would add lsscsi #2270 to this list as well.

[mathuin]

I am excited at the idea of these utilities being available in a single package.

That being said, is there a hello-world build-your-own SPK toolkit or something, so I can build screen for my DS416j and start using it before you guys get around to finishing bikeshedding? :-)

[cytec]

@mathuin screen is already here: https://synocommunity.com/package/diskutils

[mathuin]

@cytec thanks for the pointer -- never would have looked at disk tools, even though my immediate use case is to run several rsync's to spin up my new device. The package placed the binary in a funny place, but I found it and now I can run my rsync sessions unattended!

I like what you guys are doing, and I'm looking forward to exploring the community packages more once my new device is up and stable.

[junkb]

thanks for pointing out this thread. i'd love to see lsof considered for possible inclusion in this list, and lsblk too.

[Dr-Bean]

I have merged and published ncdu, based off of #2226. Should still be a candidate for a combined package of sorts, we'll just have to drop it from the repo again I suppose.

[ymartin59]

I would remove screen from the list, as tmux is much more interested replacement

[cytec]

@ymartin59 i'd go with both...tmux might be more interested but for some things i'd still prefer running a quick screen session... mostly if im on the road and want to do some things on laggy connections and/or run a command till it's done without beeing attached (that might as well work with tmux but im pretty used to screen for that :D)

Generally any new input/thoughts on this? Im pretty much satisfied with the way @Dr-Bean mentioned here #2261 (comment) for Grouping/Naming the SPK's

[cytec]

Based on #2261 (comment) that would be my suggestion:

Seperate SPK's for:

• nano SPK Published
• vim SPK Published
• testdisk SPK Published

CLI Monitoring Tools

• htop SPK Published
• nmon PR pending

CLI Dev Tools

• ldd
• nice
• gc cross package
• gdb cross package
• bc PR pending
• less PR pending

CLI File Manipulation

• detox PR pending
• fdupes PR pending
• coreutils cross package
• rhash PR Pending

CLI Disk Utils (already containinge2fsprogs and screen)

• ncdu PR pending
• davfs2 PR pending
• lsscsi PR pending
• fuse cross package
• tmux

Not sure about nice and testdisk maybe testdisk could be moved to CLI Disk Utils as well...

[Diaoul]

+1 ! Le 6 oct. 2017 4:35 PM, "cytec" <notifications@github.com> a écrit :

…

Based on #2261 (comment) <#2261 (comment)> that would be my suggestion: Seperate SPK's for: - nano SPK Published <https://github.com/SynoCommunity/spksrc/tree/master/spk/nano> - vim SPK Published <https://github.com/SynoCommunity/spksrc/tree/master/spk/vim> - testdisk SPK Published <https://github.com/SynoCommunity/spksrc/tree/master/spk/testdisk> CLI Monitoring Tools - htop SPK Published <https://github.com/SynoCommunity/spksrc/tree/master/spk/htop> - nmon PR pending <#2279> CLI Dev Tools - ldd - nice - bc PR pending <#2071> - less PR pending <#2075> CLI File Manipulation - detox PR pending <#2199> - fdupes PR pending <#2257> - coreutils cross package <https://github.com/SynoCommunity/spksrc/blob/master/cross/coreutils/> CLI Disk Utils (already containinge2fsprogs and screen) - ncdu PR pending <#2226> - davfs2 PR pending <#1974> - lsscsi PR pending <#2270> — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#2261 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AATe9BmFZxM_CAp_ZQEEKYkhcRcaCNUUks5spjq2gaJpZM4IHl_k> .

[ymartin59]

I appreciate this grouping too. Please add RHash #2944 to "CLI File Manipulation". I propose to prepare this package sets... and consider we will no longer update already existing mono-tool packages inviting users to switch to new CLI sets.

[ymartin59]

After a second read, I would move "testdisk" to "Disk Utilities" but leave "tmux" alone in fact...

[ymartin59]

What about an additional group "CLI Remote Shell" with tmux, screen and mosh ?

[ymartin59]

I have created an issue for each package idea. Please report there