On May 17 07:47 PM, A. Wilcox wrote:
Hi all,
I'd like to have a discussion on whether or not it would be worth it to
invest actual time and resources into the following projects before we
release 1.0. Perhaps we could even delay 1.0's release slightly, if
they are deemed critical enough.
The relative importance of these projects depend on what the goals are
for the distribution - specifically what level of technical literacy we
expect our users to have. At early adoption levels it will be relatively
high of course, but at the 1.0 release I think Adélie should be
accessible to all.
PackageKit Plugin for APK
=========================
This would allow us to have graphical UIs for installing, removing, and
updating packages with APK for "free".
As such, this is probably one of the more important projects that needs
to get going.
One thing that bothers me is that APK doesn't yet have tagging
or
category support, so every package would be in a single, large,
unwieldy list. It'd be very nice if we could add tagging first.
Of course, writing the plugin and then adding tagging to APK later is
another option.
Note that both KDE (Muon) and Gnome (gnome-packagekit) have GUI tools
built on top of PackageKit, so we would not need to write any GUIs.
Tagging can probably be added after-the-fact if it is determined that
adding this functionality to APK will take too long. As long as the
search isn't too bad things should be fine for the time being.
Parcel
======
This is the Web and CLI UI for determining package availability,
version, and architectures. Similar to Alpine's pkgdb or Gentoo's
Package Home for the Web UI, and similar to eix on the CLI.
I still think this is a very worthy endeavour, but time is a precious
commodity and I don't know if we have the time to build it before 1.0
unless 1.0 is delayed.
This can probably be pushed back for now. I kind of see it as a
trade-off with the PackageKit plugin for APK since they have similar
features, but the plugin will have some functionality that Parcel
necessarily cannot have - such as being able to install packages to the
user's system, unless something like openSUSE's "one click install"
feature[1] is implemented. That would essentially be a bridge between
Parcel and the desktop package manager, so the plugin should still be
prioritized over Parcel.
Register
========
This is the popcon-like system that will let us explore and inspect
packages that are popular (and not popular) with the user community at
large. Cadey on IRC has been writing a prototype.
This, too, seems like a very important feature for 1.0.
Can't say I disagree. I'm sure it would be very nice to know what to
prioritize, which is also the subject of this thread :)
Steam with gcompat
==================
I still have been unable to test the Steam binary on gcompat because it
requires 32-bit x86 and I don't have a 32-bit x86 installation with
gcompat anywhere. (The only 32-bit x86 install I have of Adélie,
outside of the builders, is a 500 MHz Pentium III laptop. Hardly an
amazing gaming system, that.)
I don't know if that is important enough to work on for 1.0, since you
can just use an Ubuntu chroot to play Steam games (this also prevents
the icky binary blobs from touching your rootfs). However, I will defer
to the community for that decision.
chroot is probably fine for now to keep the distro's focus narrow. I
already use a chroot for other software such as widevine (eww) and
LibreOffice, for example.
Horizon
=======
There has been renewed interest in Horizon since the linux-wiiu team has
joined us. We could likely spin partitioning out to KDE Partition
Manager (
https://www.kde.org/applications/system/kdepartitionmanager).
Since the linux-wiiu would like Horizon to use PackageKit (so that it
can handle any future pivots, if desired), it'd be a great idea to have
an APK PackageKit backend before we go back to Horizon.
This is a pretty important project, if not one of the most important
projects in my opinion. The manual installation process works, but it
isn't without bugs at times and it's certainly not intuitive to the
casual user - reminiscent of the Arch installation process, but much
more streamlined at least. A simple yet configurable installation
process is key to onboarding new users and as such I think this project
should be given priority, as well as maintenance of the manual
installation documentation.
Others?
=======
If anyone has any other 1.0 goals that aren't covered in the current
roadmap (
https://wiki.adelielinux.org/wiki/Project:Roadmap), let's
discuss them here.
It would be nice to have LibreOffice by 1.0 :) Of course, I can use my
chroot as long as need be but it's certainly very useful software for
both "Education" and "Office".
[1]:
https://en.opensuse.org/openSUSE:One_Click_Install