RFC: Comfy - a CLI framework to bring the Ubuntu cloud feeling to snappy Ubuntu Core
Martin Pitt
martin.pitt at ubuntu.com
Tue Jan 13 12:11:34 UTC 2015
Hey all,
> we have been asked a few times about adding one or another tool to
> ubuntu-core to help you get your job done.
I think this needs a more concrete definition. I take it we really
don't want to try and build a framework for development, as that would
need a gazillion packages, GUI, etc. For those cases it would be much
better to make it easy to push stuff back and forth between a regular
Ubuntu desktop and a snappy VM (or physical machine), which to me
smells more like an sshfs or 9p thing than trying to put an entire
development desktop into snappy.
By the looks of your list it sounds like you aim for a comfortable
shell environment aimed at admins? I. e. you need to be able to poke
around and see what's wrong with your snappy packages/services, but
you don't need to build/develop packages on it?
Alexander Sack [2015-01-13 12:32 +0100]:
> + ?: accountsservice - discuss if this is useful/needed
This is only really useful for graphical desktops, so "N" IMHO.
> + !!: apport -> prob. needs to be in ubuntu-core for crash reporting?
For crashes in ubuntu-core itself it might be useful, but only in the
restricted "phone" mode -- i. e. auto-submitting crashes to
errors.u.c., not Launchpad bugs (as these need a web browser and
interactivity).
> + Y: busybox-static
I think this would only make sense as part of a "rescue" mode. But our
boot never breaks, right? :-)
> + N: command-not-found - highly apt specific (asac believes); double check
Right, it tells you which apt packages you need to install for a
command. As you cannot do that on snappy anyway, I'd leave it out.
> + Y: cryptsetup
> + Y: cryptsetup-bin
If we want to support encrypted devices, this belongs into snappy
itself, not comfy.
> + Y: debconf-i18n
IMHO we don't want debconf and thus this package. You can't apt on
snappy anyway, and pretty much the only thing that would make use of
this is "dpkg-reconfigure tzdata" for selecting a different time zone.
But you can also do that with other CLI tools.
> + Y: dmidecode
Rather obsolete and unnecessary IMHO.
> + Y: ed
Urgh, how could we forget about this :-)
(Seriously, what for?)
> + Y: eject
This should be !! or N IMHO.
> + Y: ethtool
Smells more like !!
> + Y: ftp
If we really want an ftp client (I don't think we do), I'd rather have
lftp.
> + Y: fuse
> + Y: ntfs-3g
If we want to support such file systems, then these should be !!
> + Y: gdisk
Why? Repartitioning snappy sounds rather dangerous..
> + Y: git-man
> + ?: groff-base - anyone opinions?
If you want to ship manpages, I think we need that.
> + N: grub-legacy-ec2 - lets not do legacy in snappy world
+1 :-)
> + Y: hdparm
!!
> + !!?: ntpdate - does this work in snappy, maybe in core?
+1 for !!
> + Y: open-vm-tools
Do we really want to support this? ATM snappy is mostly used in QEMU,
where you can't (or shouldn't) really start sub-VMs in.
> + Y: os-prober
Supporting multiple OSes in a snappy instance starts to sound really
complex and not like something which we want to support?
> + Y: patch
N IMHO.
> + Y: perl
> + Y: perl-modules
This should be D. Or !! if we want to support Perl in snappy OS.
> + ?: policykit-1
D
> + Y: powermgmt-base
D please. This stuff is oooooooold and crufty.
> + Y: rsyslog
Or just enable persistant journal?
> + Y: sgml-base
D
> + ?: ureadahead - on first glance feels unlikely needed if we dont
> need in the core system itself
Not necessary, doesn't work under systemd anyway.
> + ?: xauth - not clear why xauth is needed on cli comfy systems
It would be useful to install and run an X app in snappy with X
forwarding (e. g. ssh -X).
> + ?: xdg-user-dirs - feels not relevant for snappy world with its
> own set of dirs; maybe snappy-user-dirs in core? :)
+1, snappy pretty much ignores FHS and XDG dirs anyway.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
More information about the snappy-devel
mailing list