For a long time, the Fedora Server Edition has provided a fairly lightweight default installation, but a fairly heavyweight DVD. This is because we opted to include a lot of infrastructure-related content on the disk, such as BIND, FreeIPA, MariaDB and PostgreSQL, among others. The reality these days is that this is probably more or less unnecessary. There's no such thing as a server that is not connected to a network and since we aren't shipping the entirety of the Fedora package collection on this disk, inevitably anyone installing from it is going to need to have access to package mirrors anyway. So I'd like to propose that we get rid of nearly the entirety of the <optionlist> section from comps.xml[1][2] and variants-fedora.xml[3]. The result will be a far smaller install DVD, less space wasted on the mirrors (both for the DVD and the install tree) and very little difference in user experience. Arguments against this have historically been that having it all on one disk is better for network-constrained environments to avoid downloading content multiple times. Realistically, however, I think this is generally going to be solved by local mirroring in most real-world scenarios. [1] https://pagure.io/fedora-comps/blob/master/f/comps-f30.xml.in [2] With the exception of the "server-hardware-support" and "guest-agents" which may be needed for proper installation, depending on the hardware. [3] https://pagure.io/pungi-fedora/blob/master/f/variants-fedora.xml _______________________________________________ test mailing list -- test(a)lists.fedoraproject.org To unsubscribe send an email to test-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

+1. Very good idea. Pozdrawiam/Best regards, Marcin Szydelski http://pl.linkedin.com/in/marcinszydelski mob. +48 793433899 pt., 15 lut 2019 o 17:01 Julen Landa Alustiza <julen(a)zokormazo.info&gt; napisał(a): > +1 here. totally agree with > > Stephen Gallagher <sgallagh(a)redhat.com&gt; igorleak hau idatzi zuen (2019 > ots. 15, or. 16:49): > >> For a long time, the Fedora Server Edition has provided a fairly >> lightweight default installation, but a fairly heavyweight DVD. This >> is because we opted to include a lot of infrastructure-related content >> on the disk, such as BIND, FreeIPA, MariaDB and PostgreSQL, among >> others. >> >> The reality these days is that this is probably more or less >> unnecessary. There's no such thing as a server that is not connected >> to a network and since we aren't shipping the entirety of the Fedora >> package collection on this disk, inevitably anyone installing from it >> is going to need to have access to package mirrors anyway. >> >> So I'd like to propose that we get rid of nearly the entirety of the >> <optionlist> section from comps.xml[1][2] and variants-fedora.xml[3]. >> The result will be a far smaller install DVD, less space wasted on the >> mirrors (both for the DVD and the install tree) and very little >> difference in user experience. >> >> Arguments against this have historically been that having it all on >> one disk is better for network-constrained environments to avoid >> downloading content multiple times. Realistically, however, I think >> this is generally going to be solved by local mirroring in most >> real-world scenarios. >> >> >> [1] https://pagure.io/fedora-comps/blob/master/f/comps-f30.xml.in >> [2] With the exception of the "server-hardware-support" and >> "guest-agents" which may be needed for proper installation, depending >> on the hardware. >> [3] https://pagure.io/pungi-fedora/blob/master/f/variants-fedora.xml >> _______________________________________________ >> test mailing list -- test(a)lists.fedoraproject.org >> To unsubscribe send an email to test-leave(a)lists.fedoraproject.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org >> > _______________________________________________ > test mailing list -- test(a)lists.fedoraproject.org > To unsubscribe send an email to test-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org > _______________________________________________ test mailing list -- test(a)lists.fedoraproject.org To unsubscribe send an email to test-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Arguments against this have historically been that having it all on one disk is better for network-constrained environments to avoid downloading content multiple times. Realistically, however, I think this is generally going to be solved by local mirroring in most real-world scenarios.

For a long time, the Fedora Server Edition has provided a fairly lightweight default installation, but a fairly heavyweight DVD. This is because we opted to include a lot of infrastructure-related content on the disk, such as BIND, FreeIPA, MariaDB and PostgreSQL, among others. The reality these days is that this is probably more or less unnecessary. There's no such thing as a server that is not connected to a network and since we aren't shipping the entirety of the Fedora package collection on this disk, inevitably anyone installing from it is going to need to have access to package mirrors anyway. So I'd like to propose that we get rid of nearly the entirety of the <optionlist> section from comps.xml[1][2] and variants-fedora.xml[3]. The result will be a far smaller install DVD, less space wasted on the mirrors (both for the DVD and the install tree) and very little difference in user experience. Arguments against this have historically been that having it all on one disk is better for network-constrained environments to avoid downloading content multiple times. Realistically, however, I think this is generally going to be solved by local mirroring in most real-world scenarios.

[1] https://pagure.io/fedora-comps/blob/master/f/comps-f30.xml.in

[2] With the exception of the "server-hardware-support" and "guest-agents" which may be needed for proper installation, depending on the hardware. [3] https://pagure.io/pungi-fedora/blob/master/f/variants-fedora.xml _______________________________________________ test mailing list -- test(a)lists.fedoraproject.org To unsubscribe send an email to test-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Yes, I agree with the proposal. I also agree that most servers will be connected to the Internet, however, I can think of some use cases where Internet connection is not wanted and an intranet is sufficient, such as:

servers also need security and bug fixes.

-- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader _______________________________________________ server mailing list -- server(a)lists.fedoraproject.org To unsubscribe send an email to server-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org

On Mon, Feb 18, 2019 at 05:48:15PM +0100, Lukas Ruzicka wrote: > > servers also need security and bug fixes. > If so and local repository is always needed ... why keep a server spin > then? Why not install from Everything netinst? Lots of people use Fedora in a server context. If we don't have a server-focused deliverable, it's really easy for overall project decisions to lean too far towards desktop use cases and not provide a balanced venue. (See historical discussions on value of LVM in Fedora, for example.)