On Thu, May 29, 2014 at 6:21 PM, Michael Cronenworth <mike(a)cchtml.com>
Matthias Clasen wrote:
These seem more aimed at the Server product. Sure, anaconda pulls these in
for installation support, but do you expect the WS product to be installed
on such a crazy network? Could anaconda make these optional?
I doubt that you'll be able to convince the Anaconda team to make them
optional. I would like to see it happen, but don't get your hopes up.
Do networks that use PPTP still exist? I hope not. We shouldn't encourage
unsecure connection types.
Yes, it's still very common
I see libvirt (and anaconda for iSCSI) requires these and it's
unfortunate. All you're missing is dhcpd/bind and the WS product is
basically the Server product.
Is virtualization important to have in the base product package list? Not
every developer uses the same virt software. Virt software is more of an
"add-on" in that the WS product's goal of being a foundation for building
Fedora/Linux applications isn't met by including libvirt by default. Yes,
it's nice to test applications and yes, I use visualization myself (not
libvirt), but my concern still stands. Perhaps this could be handled by the
Personally I think having virtualization that works out-of-the-box is an
excellent selling point and we should keep gnome-boxes (and libvirt) by
I'm not sure why it needs iscsi tho.
Would it be appropriate to include "devhelp" in the package list? We're
not shipping GTK/Qt docs, but should we?
Yes, I was going to add it tomorrow when I make the comps group.
Shipping documentation out of the box is not a good idea because
documentation can grow huge.
We still need a design on how to install developer documentation. Perhaps
devassistant should be doing it, or PackageKit integration from within
My idea is that we'll have an item in gnome-software called "Desktop SDK"
which will install all headers you need for a basic desktop app, as well as
their documentation, and that devhelp will have a link to that if it can't
find any documentation.
This is just a suggestion tho, as this is a complex problem we really need
to think what the proper flow here should be. Until we decide on that in
the GNOME desktop level, we should integrate it with DevAssistant instead.
I don't think we have enough time for a gnome-level solution for this
problem in this cycle, but integrating it in DevAssistant should be easier.
Out of the box the WS product cannot produce an application. RPMs cannot
be built (rpm-build, mock?). There is no C compiler. What about "-devel"
packages? (too heavy for download, USB, DVD?) Is this what the "Developer
assistant" application will deal with?
That's for devassistant to deal with, yes.
desktop mailing list