Improve wording and add more information to the FAQ

This commit is contained in:
Elara 2022-12-25 21:28:17 -08:00
parent bbe139f779
commit 38d191fa53
2 changed files with 58 additions and 39 deletions

View File

@ -46,7 +46,7 @@
<section class="container">
<p class="title">LURE</p>
<p class="subtitle">The AUR missing from most Linux distributions</p>
<p class="subtitle">The user repo missing from most Linux distros</p>
<hr>
<div class="columns">
<div class="column">
@ -55,11 +55,11 @@
<p class="card-header-title">Why should I use it?</p>
</div>
<div class="card-content">
LURE allows you to install your favorite software that may not be
popular enough to be placed into your distro's repos, while preserving
all the benefits of installing from repos, such as updates, easy
uninstalling, etc. It also allows developers to provide a single place
for their users to install their software.
LURE allows users to install software that may not be widely distributed
through official repositories, while still maintaining the convenience
of installation through repository sources. This includes features such
as updates and simple uninstallation. Additionally, LURE provides developers
with a central location for all their users to use to install their software.
</div>
</div>
</div>
@ -69,11 +69,11 @@
<p class="card-header-title">How does it work?</p>
</div>
<div class="card-content">
LURE works by abstracting package formats and package managers. It
builds native packages for your native package manager using AUR
PKGBUILD-like bash scripts, then installs them using that package manager.
This means that once LURE has successfully installed a package, it acts
just like any other package and can be managed without LURE.
LURE operates by abstracting package formats and package managers, enabling
the creation and installation of native packages automatically built from
PKGBUILD-like bash scripts, using the package manager already present on the system.
As a result, packages installed through LURE can be managed like any other package,
without the need for additional intervention from LURE for most operations.
</div>
</div>
</div>

View File

@ -3,6 +3,11 @@
import Footer from "../footer.svelte";
</script>
<svelte:head>
<title>FAQ | LURE Web</title>
<meta name="description" content="Frequently Asked Questions">
</svelte:head>
<Header/>
<div class="container">
@ -10,45 +15,59 @@
<br>
<p class="subtitle" id='distro-support'>Why isn't my distro supported?</p>
<p>
In order to support a distro, LURE has to be able to talk to its package manager
as well as build packages for it. Talking to the package manager is relatively simple,
LURE just needs to be told which commands to run, but the package formats are much more
complex. LURE uses <a href="https://github.com/goreleaser/nfpm">nFPM</a> to handle
package formats, and nFPM supports only <code>deb</code>, <code>rpm</code>, <code>apk</code>,
and <code>archlinux</code> package formats. When I started LURE, nFPM didn't have support for
archlinux packages, so I added it in a PR. Despite Arch having a very simple package format, it took
over 1k lines of code to implement, so supporting a distro with a different format, like
<code>xbps</code> for Void Linux, is very complicated, and may take some time.
To support a distribution, LURE must be able to communicate with its package manager and create packages for it.
Communicating with the package manager is relatively straightforward, as LURE simply needs to be provided with the necessary
commands. However, the package formats are more complex. LURE uses <a href="https://github.com/goreleaser/nfpm">nFPM</a> to
handle package formats, and nFPM currently supports only deb, rpm, apk, and archlinux package formats. When developing LURE,
support for archlinux packages was not available in nFPM, so I added it through a pull request. Despite the simplicity of the
archlinux package format, implementing support required over 1,000 lines of code. As a result, supporting a distribution with
a different package format, such as xbps for Void Linux, is very complex and time-consuming.
</p>
<hr>
<p class="subtitle" id='flatpak-snap-appimage'>Why use LURE instead of Flatpak, Snap, or AppImage?</p>
<p>
LURE is not meant to solve the same problems as Flatpak, Snap, and AppImage. These are containerized
package formats that allow the creation of a single package that works on all distros. This cross-platform package
contains the program as well as everything else needed for that program to run. It works using
something called a container, which can create issues where programs are slow to start, don't follow
your system's settings, or can't access certain parts of your system. If you want most programs to work every
time, or you're running an old distro with old packages, you should use containzerized formats.
LURE, on the other hand, does not use containers. It builds the program from source automatically and
installs it. It also doesn't have its own package format. Instead, it uses the same one as the distro
it's running on, making LURE packages act the same way as your distro's packages. This means that
unlike Snap and Flatpak, LURE is not a package manager. It simply uses your distro's package manager,
which allows you to manage the packages installed by LURE even without it installed.
LURE is not intended to address the same issues as Flatpak, Snap, and AppImage. These are containerized package formats that enable
the creation of a single package that can be used on all distributions. This cross-platform package contains the program and everything
else necessary for it to run, and it relies on containers to achieve this compatibility. However, containers can sometimes cause programs
to start slowly, fail to adhere to system settings, or be unable to access certain parts of the system. If you need most programs to
function consistently or you are using an older distribution with outdated packages, containerized formats may be the best choice. In contrast,
LURE does not use containers. It builds the program from source and installs it automatically. It also does not have its own package format.
Instead, it uses the same format as the distribution it is running on, so LURE packages behave like the distribution's native packages.
This means that unlike Snap and Flatpak, LURE is not a package manager; it simply uses the distribution's package manager, allowing you to
manage the packages installed through LURE even when LURE is not installed.
</p>
<br>
<p>
However, LURE also has some downsides. Because of the fact that it builds programs automatically from source,
certain packages, especially git packages that retrieve the latest code from git, may not work on older distros,
or distros like Debian which have old packages. Please consider your use case and whether such downsides are
acceptable before using LURE. Also note that, like the AUR, all packages are user-submitted and are not vetted,
so while unlikely, they may contain malicious code. It is the responsibility of the user to read the build script
and ensure this is not the case. Malicious packages should be reported by opening an issue on the git repo containing them.
However, LURE also has some drawbacks. Since it builds programs from source, certain packages, particularly git packages that
retrieve the latest code from git, may not work on older distributions or distributions like Debian that have outdated packages.
Please consider your specific needs and whether these downsides are acceptable before using LURE. Additionally, similar to the AUR,
all packages are user-submitted and not vetted, so while it is unlikely, they may contain malicious code. It is the responsibility
of the user to review the build script to ensure this is not the case. If you come across a malicious package, please report it by
opening an issue on the git repository containing it.
</p>
<hr>
<p class="subtitle" id="handling-dependencies">How does LURE handle dependencies across distros?</p>
<p>
LURE manages dependencies across distributions by offering distro overrides, in which package maintainers can specify different
variables and functions for each distribution. The most specific override is given precedence. After the overrides are resolved,
LURE compares the resulting list of dependencies with the packages installed on the system and filters out any that are already
installed. For the remaining dependencies, LURE checks its own repositories to see if each package is available there. If it is,
LURE installs it from its repositories. If the package is not found in any repository, LURE passes the dependency on to the package
manager, which handles dependency resolution and installation.
</p>
<hr>
<p class="subtitle" id="testing">How can one test a LURE package to ensure it works?</p>
<p>
Docker is recommended for testing LURE packages on different distros. It provides a clean image of any distribution, which is very
useful for testing as it can help catch issues that might not manifest themselves on your system. Eventually, an automated
docker-based testing tool is planned, but in the meantime, this will need to be done manually for each distribution you're planning
to support. To find package names for each distribution, you can use <a href="https://repology.org">repology.org</a> and
<a href="https://pkgs.org">pkgs.org</a>. These websites maintain comprehensive databases of package repositories for various distributions.
</p>
<hr>
<p class="subtitle" id='adding-packages'>How do I add my own package to LURE?</p>
<p>
Take a look at the documentation for <a href="https://github.com/Arsen6331/lure/blob/master/docs/build-scripts.md">Build Scripts</a>
and <a href="https://github.com/Arsen6331/lure/blob/master/docs/adding-packages.md">Adding Packages to LURE's repo</a>.
To add your own package, please refer to the <a href="https://github.com/Arsen6331/lure/blob/master/docs/packages">package documentation</a> provided by LURE.
</p>
</div>