Closed Vouivre closed 3 years ago
Interesting...
So if you would prefer that it simply requires awk
and whatever downsides that choice carries are fine, I'm okay with you trying to maintain that patch.
However, you can definitely just build a single static binary from the util-linux
source. Something like make column
after running the configure step will produce a static column
. Alternatively, we could just do it ourselves with a few extra lines, though we'd still have to provide the required source; this is what the Makefile
runs when you just build column
:
--- lib/libcommon_la-blkdev.lo ---
--- lib/libcommon_la-buffer.lo ---
--- lib/libcommon_la-canonicalize.lo ---
--- lib/libcommon_la-color-names.lo ---
--- lib/libcommon_la-cpuset.lo ---
--- lib/libcommon_la-crc32.lo ---
--- lib/libcommon_la-crc32c.lo ---
--- lib/libcommon_la-encode.lo ---
--- lib/libcommon_la-env.lo ---
--- lib/libcommon_la-fileutils.lo ---
--- lib/libcommon_la-idcache.lo ---
--- lib/libcommon_la-jsonwrt.lo ---
--- lib/libcommon_la-linux_version.lo ---
--- lib/libcommon_la-loopdev.lo ---
--- lib/libcommon_la-mangle.lo ---
--- lib/libcommon_la-match.lo ---
--- lib/libcommon_la-mbsalign.lo ---
--- lib/libcommon_la-mbsedit.lo ---
--- lib/libcommon_la-md5.lo ---
--- lib/libcommon_la-pager.lo ---
--- lib/libcommon_la-path.lo ---
--- lib/libcommon_la-procutils.lo ---
--- lib/libcommon_la-pwdutils.lo ---
--- lib/libcommon_la-randutils.lo ---
--- lib/libcommon_la-blkdev.lo ---
CC lib/libcommon_la-blkdev.lo
--- lib/libcommon_la-buffer.lo ---
CC lib/libcommon_la-buffer.lo
--- lib/libcommon_la-canonicalize.lo ---
CC lib/libcommon_la-canonicalize.lo
--- lib/libcommon_la-color-names.lo ---
CC lib/libcommon_la-color-names.lo
--- lib/libcommon_la-cpuset.lo ---
CC lib/libcommon_la-cpuset.lo
--- lib/libcommon_la-crc32.lo ---
CC lib/libcommon_la-crc32.lo
--- lib/libcommon_la-crc32c.lo ---
CC lib/libcommon_la-crc32c.lo
--- lib/libcommon_la-encode.lo ---
CC lib/libcommon_la-encode.lo
--- lib/libcommon_la-env.lo ---
CC lib/libcommon_la-env.lo
--- lib/libcommon_la-fileutils.lo ---
CC lib/libcommon_la-fileutils.lo
--- lib/libcommon_la-idcache.lo ---
CC lib/libcommon_la-idcache.lo
--- lib/libcommon_la-jsonwrt.lo ---
CC lib/libcommon_la-jsonwrt.lo
--- lib/libcommon_la-linux_version.lo ---
CC lib/libcommon_la-linux_version.lo
--- lib/libcommon_la-loopdev.lo ---
CC lib/libcommon_la-loopdev.lo
--- lib/libcommon_la-mangle.lo ---
CC lib/libcommon_la-mangle.lo
--- lib/libcommon_la-match.lo ---
CC lib/libcommon_la-match.lo
--- lib/libcommon_la-mbsalign.lo ---
CC lib/libcommon_la-mbsalign.lo
--- lib/libcommon_la-mbsedit.lo ---
CC lib/libcommon_la-mbsedit.lo
--- lib/libcommon_la-md5.lo ---
CC lib/libcommon_la-md5.lo
--- lib/libcommon_la-pager.lo ---
CC lib/libcommon_la-pager.lo
--- lib/libcommon_la-path.lo ---
CC lib/libcommon_la-path.lo
--- lib/libcommon_la-procutils.lo ---
CC lib/libcommon_la-procutils.lo
--- lib/libcommon_la-pwdutils.lo ---
CC lib/libcommon_la-pwdutils.lo
--- lib/libcommon_la-randutils.lo ---
CC lib/libcommon_la-randutils.lo
--- lib/libcommon_la-sha1.lo ---
CC lib/libcommon_la-sha1.lo
--- lib/libcommon_la-signames.lo ---
--- lib/libcommon_la-strutils.lo ---
--- lib/libcommon_la-signames.lo ---
CC lib/libcommon_la-signames.lo
--- lib/libcommon_la-strutils.lo ---
CC lib/libcommon_la-strutils.lo
--- lib/libcommon_la-strv.lo ---
CC lib/libcommon_la-strv.lo
--- lib/libcommon_la-sysfs.lo ---
CC lib/libcommon_la-sysfs.lo
--- lib/libcommon_la-timeutils.lo ---
CC lib/libcommon_la-timeutils.lo
--- lib/libcommon_la-ttyutils.lo ---
CC lib/libcommon_la-ttyutils.lo
--- libsmartcols/src/la-buffer.lo ---
CC libsmartcols/src/la-buffer.lo
--- libsmartcols/src/la-calculate.lo ---
CC libsmartcols/src/la-calculate.lo
--- libsmartcols/src/la-cell.lo ---
--- libsmartcols/src/la-column.lo ---
--- libsmartcols/src/la-cell.lo ---
CC libsmartcols/src/la-cell.lo
--- libsmartcols/src/la-column.lo ---
CC libsmartcols/src/la-column.lo
--- libsmartcols/src/la-grouping.lo ---
CC libsmartcols/src/la-grouping.lo
--- libsmartcols/src/la-init.lo ---
CC libsmartcols/src/la-init.lo
--- libsmartcols/src/la-iter.lo ---
CC libsmartcols/src/la-iter.lo
--- libsmartcols/src/la-line.lo ---
CC libsmartcols/src/la-line.lo
--- libsmartcols/src/la-print-api.lo ---
CC libsmartcols/src/la-print-api.lo
--- libsmartcols/src/la-print.lo ---
CC libsmartcols/src/la-print.lo
--- libsmartcols/src/la-symbols.lo ---
CC libsmartcols/src/la-symbols.lo
--- libsmartcols/src/la-table.lo ---
CC libsmartcols/src/la-table.lo
--- libsmartcols/src/la-version.lo ---
CC libsmartcols/src/la-version.lo
--- libsmartcols/src/la-walk.lo ---
CC libsmartcols/src/la-walk.lo
--- text-utils/column-column.o ---
CC text-utils/column-column.o
--- libcommon.la ---
CCLD libcommon.la
--- libsmartcols.la ---
CCLD libsmartcols.la
--- column ---
CCLD column
Interesting...
So if you would prefer that it simply requires
awk
and whatever downsides that choice carries are fine, I'm okay with you trying to maintain that patch.However, you can definitely just build a single static binary from the
util-linux
source. Something likemake column
after running the configure step will produce a staticcolumn
. Alternatively, we could just do it ourselves with a few extra lines, though we'd still have to provide the required source; this is what theMakefile
runs when you just buildcolumn
:
hhhmmm, I had it from the beginning, sorry....
What you mean exactly with:
Alternatively, we could just do it ourselves with a few extra lines, though we'd still have to provide the required source
You mean providing the necessary sources to only build column
and writing the code to compile only
column
? If yes, what is the advantage ? I find it simpler to use directly util-linux
.... now that I have understand my mistake ;-)
You mean providing the necessary sources to only build column and writing the code to compile only column...
Yes this is what I mean -- the advantage is that people wouldn't have to download the entire util-linux
source just for column
. I'm not particularly married to any solution here though.
I had a look and I can build only column
, if I download the whole tarball. That's not a problem. But I'm curious with the other solution (download only the necessary files). What I know for the moment:
at the moment I'm unable to write a complicated Makefile with a lot of variables. When you write "writing the code to compile only column", do you mean something like
gcc library1 library2
or a bigger Makefile
which checks the environment of the system ?
Well I'm not entirely certain exactly what column
itself requires besides one specific library util-linux
builds -- I would assume it's simply a matter of creating all the object files for that library and then linking them, and then after that simply making column
from column.c
.
All that being said, it would be fine to simply bundle util-linux
.
All that being said, it would be fine to simply bundle
util-linux
.
I will keep in mind your suggestions. I think at the moment it's best to add util-linux
.
It could change later.
PR to close this discussion: https://github.com/kiss-community/community/pull/643
Thank you for your help ;-).
At the moment
ytfzf
doesn't work and has to be fixed. The dependencyutil-linux
is needed, more precisely, the commandcolumn
provided byutil-linux
is needed. I don't know if something changed with the switch to wayland, because before it was not necessary.... or at the time I created the package.column
was introduced with version 1.1.4: https://github.com/pystardust/ytfzf/releases/tag/v1.1.4With the use of
column
, it' possible to align properly some information. With the goal of kisslinux, I find it would be a good choice to avoid this dependency. So the possible fixes I see:util-linux
as a dependency: in my opinion it's too much for only one tool,column
.column
inutil-linux
: in my opinion bad, because it's not possible to create a single binary. Such a package would have also some libraries, which would be in conflict if somebody wants to install the whole packageutil-linux
column
and create a lightweight package: the source of the package has to be maintained in that case.column
: useawk
. The information won't be properly aligned, but I expectytfzf
is perfectly usable. I patch should be created and probably it shouldn't be adapted at each release.@dilyn-corner : what would be your preferred solution ? Something else ?
In my opinion the fourth proposal it's the best.
My goal is to provide a lightweight version for kisslinux users and not check regularly if a new version is available.