Closed cytec closed 6 years ago
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:
Combined:
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.
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:
cross
aren't considered (ex: unrar which seems pretty "essential" too)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.
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.
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.
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)...
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:
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
...We would add lsscsi #2270 to this list as well.
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? :-)
@mathuin screen is already here: https://synocommunity.com/package/diskutils
@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.
thanks for pointing out this thread. i'd love to see lsof considered for possible inclusion in this list, and lsblk too.
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.
I would remove screen
from the list, as tmux
is much more interested replacement
@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 https://github.com/SynoCommunity/spksrc/issues/2261#issuecomment-211224194 for Grouping/Naming the SPK's
Based on https://github.com/SynoCommunity/spksrc/issues/2261#issuecomment-211224194 that would be my suggestion:
Seperate SPK's for:
CLI Monitoring Tools
CLI Dev Tools
CLI File Manipulation
CLI Disk Utils
(already containinge2fsprogs
and screen
)
Not sure about nice
and testdisk
maybe testdisk
could be moved to CLI Disk Utils
as well...
+1 !
Le 6 oct. 2017 4:35 PM, "cytec" notifications@github.com a écrit :
Based on #2261 (comment) https://github.com/SynoCommunity/spksrc/issues/2261#issuecomment-211224194 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 https://github.com/SynoCommunity/spksrc/pull/2279
CLI Dev Tools
- ldd
- nice
- bc PR pending https://github.com/SynoCommunity/spksrc/pull/2071
- less PR pending https://github.com/SynoCommunity/spksrc/pull/2075
CLI File Manipulation
- detox PR pending https://github.com/SynoCommunity/spksrc/pull/2199
- fdupes PR pending https://github.com/SynoCommunity/spksrc/pull/2257
- coreutils cross package https://github.com/SynoCommunity/spksrc/blob/master/cross/coreutils/ CLI Disk Utils (already containinge2fsprogs and screen)
- ncdu PR pending https://github.com/SynoCommunity/spksrc/pull/2226
- davfs2 PR pending https://github.com/SynoCommunity/spksrc/pull/1974
- lsscsi PR pending https://github.com/SynoCommunity/spksrc/pull/2270
— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/SynoCommunity/spksrc/issues/2261#issuecomment-334773089, or mute the thread https://github.com/notifications/unsubscribe-auth/AATe9BmFZxM_CAp_ZQEEKYkhcRcaCNUUks5spjq2gaJpZM4IHl_k .
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.
After a second read, I would move "testdisk" to "Disk Utilities" but leave "tmux" alone in fact...
What about an additional group "CLI Remote Shell" with tmux, screen and mosh ?
I have created an issue for each package idea. Please report there
Already mentioned here: https://github.com/SynoCommunity/spksrc/pull/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:
New:
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.