search

SynoCommunity / spksrc

Cross compilation framework to create native packages for the Synology's NAS
https://synocommunity.com
Other
3.01k stars 1.23k forks source link

Provide a "CLI Essentials" SPK? #2261

Closed cytec closed 6 years ago

cytec commented 8 years ago

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.

Dr-Bean commented 8 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.

cytec commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

biyiklioglu commented 8 years ago

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

mathuin commented 8 years ago

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 commented 8 years ago

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

mathuin commented 8 years ago

@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 commented 7 years ago

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

Dr-Bean commented 7 years ago

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 commented 7 years ago

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

cytec commented 6 years ago

@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

cytec commented 6 years ago

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...

Diaoul commented 6 years ago

+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:

CLI Monitoring Tools

CLI Dev Tools

CLI File Manipulation

— 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 .

ymartin59 commented 6 years ago

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 commented 6 years ago

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

ymartin59 commented 6 years ago

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

ymartin59 commented 6 years ago

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