view release on metacpan or  search on metacpan

bin/rs  view on Meta::CPAN

    # show a list of modules that are orphaned (i.e. not referenced by anybody)
    rs orphan

    # adopt all the orphans and you will never be able to see them again.
    rs adopt

=head1 DESCRIPTION

(Please see the section L</CPAN> and
L<my TPF proposal|https://github.com/057a3dd61f99517a3afea0051a49cb27994f94d/rslinux/blob/rs/TPF-proposal.pod>
for my ongoing effort to marry C<App::rs> and CPAN.)

RSLinux was born out of desire for freedom. Back in 2012, I was using
ArchLinux, as with many distributions at that time, it's switching to
systemd, and I would be forced to switch to it if I chose to update. It
frustrated me deeply, as I always seek freedom, from a very young age, and I
knew from my own experience that no matter how wonderful a thing is, it
will become a demon that haunts me once I'm being forced to do it. I made
up my mind to create something of my own so that I have complete freedom
to choose how it would be.

At first, I got my hand dirty with LFS, succeeded and got pretty satisfied
with it. Later in 2013, I made it again without following the LFS book, I
tried a different bootstrapping process with what I thought was right and
necessary, and it fits my mind much better. I typically rebuild my system
on an annual basis, after I did it in 2014 I gradually realized its problem,
without a package manager, thus an easy way to remove installed package,
I tended to dislike denpendency, and prefer a minimalist system, which
prevented me to explore since I knew I would have no easy way to clean up the mess
after I installed a lot of things, experimented with them a bit, and then
decided that I don't want them anymore.

I knew it was bad, and something to be dealt with. In the end of 2015, I
was working on something that's recursive, and it inspired me to
write a simple and elegant package manager B<rs>, since directory and files,
which a package manager deals everyday, recursiveness is in their nature.

B<rs> keeps a database of the metadata of every file/directory that you didn't ask
it to ignore, you will typically ask it to ignore something like C</tmp>,
C</proc>, etc., if you're using it to manage system wide packages. With
B<rs> you compile and install a package from source as usual, and when the
installation process is done, you run C<rs diff oid>, B<rs> then starts
a scan of the root directory into which you just installed your package,
and during the scan process, it compares what's actually there with the
database, calculate the difference between them as well as updating the
database, and when the scan process ends, the difference is then tagged
as C<oid> in the database, serialized and stored as C<oid.rs>, and the
database is saved as well.

This serialized difference is what B<rs> considers as a package, and it could
be transferred across machines and installed using C<rs patch>, it's very
much like a tarball, but I could not just use a tarball since I need to maintain
all these metadata in the database when patching, instead of parsing a tarball
I thought I might just use a trivial binary format that integrates well with
B<rs> and suits my need.

Being someone who came from LFS, I knew this is a game changer, it gave me a
complete new experience, besides the ability to explore without any hesitation,
I could easily upgrade, or switch between multiple versions of package;
I could now compile once on desktop, and then install the compiled package
on laptop, or vps; I could select a few packages, patch them, and then make
a bootable usb disk or cdrom, or a complete environment that's suitable to
put into a container and run web service. I sincerely believe anyone who
likes LFS will like it, and anyone who likes the freedom of LFS but hated
the inconvenience will like it also, since B<rs> eliminates ninety percent
of the inconvenience yet without sacrificing even a tiny bit of the freedom.

RSLinux is a Linux distribution, but not necessarily so, it's a way of doing
things more. You do not need to take a full commitment using it as a
distribution, there're almost always packages that you care about more and
want to follow closely, while other people haven't packaged it for you,
B<rs> is a perfect choice for this, you could use B<rs> to properly manage
packages somewhere inside your home directory while still using your
favorite distribution.

Till this day, I still haven't tried systemd once, I don't know one single
objective reason why I don't use it, but it's true enough that it's the
very first motivation that got all these things started. I guess that's just
how the world is, few things are objective while basically everything is
subjective. Nevertheless, the goal of B<rs> is to avoid all these subjective
feelings and views on how a distribution should be made, which init system
should be used, what configure switches, compiling flags should be passed,
whether stable version should be preferred over bleeding edge version or the
other way around, how a filesystem hierarchy should be laid out. Whatever
you feel is right, you just go for it, and what B<rs> does is to make this
process easier. Since the packaging by C<diff> method is general, it works
with every single package with no exception, you don't need any tweak for
an individual package, thus most packages need zero configuration, and all
the build instructions I used to build a distribution that I use everyday
are only literally one hundred lines long.

Still, RSLinux will never be easier than a classic distribution where other
people do everything for you, but there're still many things to do and
improve, and I do think in the long run the effort will be negligible
and the reword will be immense. If you never tried LFS or something like
it before, I suggest you use B<rs> to manage a couple of packages user wide
while retain your distribution untouched, once you get your way around it,
then maybe consider to jump on the ship, there's nothing to be afraid of.

=head1 OPTIONS

=over 4

=item * --root=<dir>

Specify the directory in which B<rs> will operate, it will scan this
directory for newly installed files during a C<diff> operation, and
will put or remove files under it during a C<patch>, C<remove> operation
respectively.

=item * --db=<file>

Specify the database where all the metadata of the files and directories
in C<root> is stored. If it doesn't exist yet B<rs> will create an empty
one for you. But you should always specifiy it since it's used by
all of the commands.

=item * --pool=<dir>

The direcory where a generated package will be stored during a C<diff>