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
Received on Fri May 18 2018 - 15:09:57 UTC