search

clearlinux / distribution

Placeholder repository to allow filing of general bugs/issues/etc against the Clear Linux OS for Intel Architecture linux distribution
524 stars 29 forks source link

micro (terminal-based text editor) #2662

Open ReFleXzZ opened 2 years ago

ReFleXzZ commented 2 years ago

Official package name: micro

Link to Repository: https://github.com/zyedidia/micro

License (must be an OSI approved Open Source license): MIT License

Download URL of latest release: Version 2.0.10 (Source files): https://github.com/zyedidia/micro/archive/refs/tags/v2.0.10.tar.gz

Version 2.0.10 (Binary): https://github.com/zyedidia/micro/releases/download/v2.0.10/micro-2.0.10-linux64.tar.gz

Version 2.0.10 (Static Binary): https://github.com/zyedidia/micro/releases/download/v2.0.10/micro-2.0.10-linux64-static.tar.gz

Latest release date (must be recent): August 7th, 2021

Latest commit: Jun 25, 2022

Description: (Copied from repo-page) micro is a terminal-based text editor that aims to be easy to use and intuitive, while also taking advantage of the capabilities of modern terminals. It comes as a single, batteries-included, static binary with no dependencies.

bryteise commented 2 years ago

It looks like go project that doesn't vendor its dependencies as part of their release archive. These aren't usually the types of projects we package. On the upside, the upstream project makes binary releases as you've noted.

ReFleXzZ commented 2 years ago

On the other hand, git and Go are, as far as I know, the only dependencies when you compile it by yourself, which are also available in the official repositories of Clear Linux*. But I understand what you mean.

bryteise commented 2 years ago

Right, if you build online (which our builders do not) it doesn't need much.

phmccarty commented 2 years ago

The dependencies in question are listed in the go.mod file: https://github.com/zyedidia/micro/blob/v2.0.10/go.mod

When an upstream project ships either (a) the vendor/ tree in the source tree (example: faas-cli), or (b) a dist tarball containing the vendor tree (example: abireport release asset abireport-1.0.11.tar.xz), then packaging becomes much easier. If the vendor tree for a package is not readily available, we have to pre-build it ourselves and ship it via an autospec "archive". This pre-work is of course technically possible, and we do ship some packages that take this approach, but my understanding is that we would prefer not to treat the autospec archive approach as a BKM...

ReFleXzZ commented 2 years ago

And what would be if you would do it like Arch Linux does it, so the user would need to compile it by his own at download, without the users need to act? Or is that also not a BKM?