Bug 875433 - anaconda only allows 1 DE to be selected-this is a regression from what used to occur
Summary: anaconda only allows 1 DE to be selected-this is a regression from what used ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 18
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 894332 905306 995705 (view as bug list)
Depends On: 865922
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-11 06:54 UTC by Steven Haigh
Modified: 2013-08-21 19:07 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 865922
Environment:
Last Closed: 2012-11-12 21:32:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Steven Haigh 2012-11-11 06:54:17 UTC
+++ This bug was initially created as a clone of Bug #865922 +++

Description of problem:
anaconda only allows 1 DE to be selected-this is a regression from what used to occur

Version-Release number of selected component (if applicable):
Anaconda 18.14 on netinstall and DVD
http://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC3/Fedora/x86_64/iso/Fedora-18-Beta-TC3-x86_64-netinst.iso

Anaconda 18.15
http://dl.fedoraproject.org/pub/alt/qa/18/20121010_f18b-smoke7/Fedora-18b-smoke7-x86_64-netinst.iso

How reproducible:
Try to select more than on Desktop ie; Gnome and sugar-desktop
It is not possible any more
Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:
install 2 DE's 

Additional info:

--- Additional comment from clumens on 2012-10-13 07:09:50 EST ---

Right, what we're going for here is trying to present Fedora as a more cohesive thing where you pick what your basic system is and then add stuff to it.  The basic system is the environment on the left, and the stuff you add to it is the add-ons on the right.  We are trying to get away from the big grab-bag of crud where you just throw together whatever.

If you really really want to do this, you can of course add packages from your installed system.

--- Additional comment from jbwillia.edu on 2012-10-13 07:58:16 EST ---

This is really a drawback for alot of people who setup machines for the family with different desktops or setup a lab environment 

this will add multiple hours to me installs thanks guys for not advertising this earlier.

--- Additional comment from awilliam on 2012-10-13 09:27:32 EST ---

You can still do multiple desktop installs using a kickstart file, note.

--- Additional comment from satellit on 2012-10-13 13:00:55 EST ---

Example  kickstart files need to be supplied for all available DE's on fedora's website with instructions on how to apply them to anaconda. 
This method still seems to be a major barrier for the use case of a teacher (off the internet) in a third world classroom trying to install gnome and sugar to a students PC. The "sneaker-net" case. Can the ,ks files be combined like "yum install livecd-creator livecd-tools spin-kickstarts" ?

--- Additional comment from jkeating on 2012-10-13 17:43:05 EST ---

The way the newui works you can supply a kickstart with just the %packages data.  You will be prompted for all other settings.  I believe we're going to do some work to allow putting environments into the kickstart file as well as groups and packages, eg:

%packages
@standard
@^gnome-desktop
@^kde-desktop
%end

In the above stanza, "standard" is a group, the other two are environments, matching up to the choices you see in the graphical UI.

--- Additional comment from dan.mashal on 2012-10-17 04:46:26 EST ---

I'm reopening this bug. 

This is a really BAD idea in my personal opinion.

I have been installing all the DE's off the DVD for as long as I can remember and this is really frustrating. 

Somewhat related:

You also have to actually click the actual radio button, you cannot double click or single click any feature or addon. 

These are both really bad design choices and many people have express very serious concerns over the original issue this bug is opened about. 

What needs to happen to change the development team's mind on this?

--- Additional comment from dan.mashal on 2012-10-17 04:47:00 EST ---

And no, I'm not going to use kickstart to do this.

--- Additional comment from awilliam on 2012-10-17 06:59:25 EST ---

re commonbugs - as this is a design choice not a bug it should be documented in release notes, not commonbugs.

--- Additional comment from dan.mashal on 2012-10-30 20:13:21 EST ---

Is this getting fixed or is this an F18 NTH and an F19 requirement?

Please reply.

--- Additional comment from pbrobinson on 2012-10-30 20:48:03 EST ---

I'm not sure why I've been added to this bug. There was discussion somewhere about it (I don't remember where) and when I was asked I responded with as long as it can be done post install with a "yum install @some-desktop" I had no issues with it. 

I don't believe it will add multiple hours, nor do I believe it's an issue for "third world classroom trying to install gnome and sugar" as they should be doing it via a custom live image or kickstart install, neither of which are impacted by this change.

--- Additional comment from dan.mashal on 2012-10-30 20:49:26 EST ---

You were added for your 2 cents.

And I ask you what about the normal desktop power user?

--- Additional comment from pbrobinson on 2012-10-30 20:55:14 EST ---

(In reply to comment #11)
> You were added for your 2 cents.
> 
> And I ask you what about the normal desktop power user?

The "normal desktop power user" would be more than capable of installing a second/third/forth desktop post install using either the GUI PackageKit solution for the primary/initial desktop that they installed or via yum. It should be documented properly though.

--- Additional comment from duffy on 2012-10-31 01:20:11 EST ---

If you need to install more than one desktop you have two options:

1) Upload a kickstart file with just a %packages section with the desktops you'd like installed listed, upload it to your fedorapople page, at syslinux hit Tab and type ks="http://username.fedorapeople.org/my.ks" and you can go through the installer with the packages you need for those desktops selected.

2) Install the desktops post-install using yum groupinstall.

The use case is accounted for so I'm closing this bug.

Comment 1 Steven Haigh 2012-11-11 06:54:38 UTC
Having just stumbled across this, I do not believe this is a good design choice.

While I can see the benefit for the development team on just funnelling one desktop down the users throat, from a user perspective there is no benefit.

While I have been using various linux distros for over 12 years, I have never once configured a kickstart file - nor have I ever needed to. I don't always have a web server handy, network connection, nor internet connectivity at install time. This would make kickstarting (from what I've read) rather difficult.

As such, re-opening for consideration (and hopefully not being closed as a 'nup, dont care').

Comment 2 Andre Robatino 2012-11-11 12:09:27 UTC
In particular I'd like to see a more careful consideration of the requirements for using kickstart than "upload a kickstart file to your fedorapeople account", considering that the vast majority of Fedora users don't have one (there are about 4000 user accounts in /home/fedora on fedorapeople.org, divide that by the estimated number of Fedora users). Some acknowledgement that not everyone has unlimited bandwidth yet would also be nice. It's possible to do the yum groupinstall bandwidth-free from the DVD by setting it up as a local repo after the install and being careful during the install to disable downloading updates. (BTW, I don't understand that default for the DVD, since many/most people who choose to use a large image full of obsolete packages - the DVD - rather than the netinst are probably doing it because their bandwidth is limited and it's faster for them to install the old packages first and then update using presto.) However, this is a significant inconvenience especially when the installer could just allow an arbitrary set of DEs rather than just one. And what's the point of having the installer prevent something that the developers themselves claim is so easy to change afterwards?

I think there should be some sort of general policy that ideally anything that's easy to configure after the install should be easy to set up during the install - of course with the understanding that sometimes there may not be time to write the necessary code, but considering that the anaconda devs seem unanimous that they *want* the installer to work this way, I don't think limited resources are the real issue here. (And no, kickstart is not easy, not compared to being allowed to check multiple DE boxes.)

Comment 3 Andre Robatino 2012-11-11 12:21:41 UTC
Should probably modify the suggested policy to be something like "the installer shouldn't go out of its way to make difficult something that's easy after the install". Of course there are a million easy ways to customize, and the installer can't be expected to include all of them, since it makes the UI more complicated. But in this case we're talking about a choice between allowing only one DE vs. an arbitrary set, and obviously being allowed to check an arbitrary set of boxes doesn't do that.

Comment 4 Dan Mashal 2012-11-12 01:18:56 UTC
No.. you should all learn kickstart! Because that's a great way to install Fedora!

Comment 5 Dan Mashal 2012-11-12 01:19:23 UTC
Probably better than Anaconda too!

Comment 6 Chris Lumens 2012-11-12 04:39:08 UTC
Good one!

Oh, wait, kickstart is the same code as anaconda.

Comment 7 Dan Mashal 2012-11-12 04:41:57 UTC
Oh wait, Anaconda still can't install multiple desktops! 


BTW clumens I owe you a 12 pack of beer.

Comment 8 satellitgo 2012-11-12 10:13:39 UTC
(In reply to comment #7)
> Oh wait, Anaconda still can't install multiple desktops! 
> 
> 
> BTW clumens I owe you a 12 pack of beer.

It does install multiple DE's if you select
 "basic -x" (scroll down to bottom of left list)
and select them from right list in TC8 and smoke17 DVD and netinstall: anaconda 18.28

mate, sugar and cinnamon are not available this way

Comment 9 Dan Mashal 2012-11-12 11:37:45 UTC
hmmmmmmmmmmmm

Comment 10 Andre Robatino 2012-11-12 14:48:07 UTC
(In reply to comment #8)

> It does install multiple DE's if you select
>  "basic -x" (scroll down to bottom of left list)
> and select them from right list in TC8 and smoke17 DVD and netinstall:
> anaconda 18.28
> 
> mate, sugar and cinnamon are not available this way

Now THAT'S an easy workaround. Click, click, click. I verified that it works for a Gnome/KDE install. It's a little unfortunate that the devs insist on making the UI slightly more complicated than it has to be due to allowing only one choice in the left column while allowing multiple choices in the right column, rather than making them work exactly the same and allowing multiple choices in both, but whatever.

The missing DEs should be added in the right column for consistency, though.

Comment 11 David Lehman 2012-11-12 15:57:05 UTC
What is so hard about launching the graphical software installation tool after installation and installing all twenty DEs if you so desire?

Anaconda is an OS installer. It has installed your OS. It has done all the _necessary_ configuration. You are free after installing the OS to customize it to whatever extent pleases you most.

Comment 12 Máirín Duffy 2012-11-12 17:02:40 UTC
Steven,

"While I have been using various linux distros for over 12 years, I have never once configured a kickstart file - nor have I ever needed to."

I would be surprised if you had with any distro that wasn't Fedora or Red Hat based since kickstart is anaconda-specific.

"I don't always have a web server handy, network connection, nor internet connectivity at install time. This would make kickstarting (from what I've read) rather difficult."

We did consider this, and it is our intention to enable users to supply kickstarts or kickstart snippets via a USB key plugged into the machine at the time of booting the installer, which we will auto-detect and allow the user to use as part of their installation configuration. We've had to push this feature back from being included in Fedora 18 for more high-priority features, but all of the plumbing is in place to make this happen.

If you'd like to see mockups of this system, my intern developed a set that she blogged on planet Fedora right here:

http://beefybeliever.wordpress.com/2012/07/26/kickstart-autodetection/

Comment 13 Máirín Duffy 2012-11-12 17:08:51 UTC
Andre,

"In particular I'd like to see a more careful consideration of the requirements for using kickstart than "upload a kickstart file to your fedorapeople account", considering that the vast majority of Fedora users don't have one"

See my comment to Steven above (comment #12)

"I think there should be some sort of general policy that ideally anything that's easy to configure after the install should be easy to set up during the install"

I don't think that policy makes sense. The installer is a necessarily limited environment (we don't have things like a panel, or normal window management, or the ability to pop up a browser to research choices before you make them) and we have actually deliberately focused on collecting the bare minimum necessary to get you to a working environment where you can much better and with a higher rate of success make those customizations and other decisions.

From a usability POV, the installer environment being necessarily different than a typical desktop environment, what you propose would amount to maintaining two versions of every configuration utility (not sustainable), which will look and feel differently to users (poor consistency = bad user experience), and which will each have their own unique sets of bugs due to being separate implementations further confounding users (again, bad.) 

So I don't think this proposal has much merit, I'm sorry to say :( I understand where you are coming from but the install environment is just not a full environment.

Comment 14 Máirín Duffy 2012-11-12 17:09:37 UTC
Dan,

"hmmmmmmmmmmmm"

Grow up.

Comment 15 Andre Robatino 2012-11-12 18:07:39 UTC
(In reply to comment #13)

> "I think there should be some sort of general policy that ideally anything
> that's easy to configure after the install should be easy to set up during
> the install"
> 
> I don't think that policy makes sense. The installer is a necessarily
> limited environment (we don't have things like a panel, or normal window
> management, or the ability to pop up a browser to research choices before
> you make them) and we have actually deliberately focused on collecting the
> bare minimum necessary to get you to a working environment where you can
> much better and with a higher rate of success make those customizations and
> other decisions.

I had realized this in my immediate followup comment 3, where I suggested instead "the installer shouldn't go out of its way to make difficult something that's easy after the install". Although the existence of the easy workaround in comment 8 makes this whole bug pretty much moot - to select multiple DEs, choose @basic_x, then the DEs move over to the right column where any set can be selected. It seems silly to me to have to do that, but as long as it's easy, I don't care.

Comment 16 Steven Haigh 2012-11-12 19:08:55 UTC
Sorry, with all respect David... Where do we draw the line on this?

If Anaconda is an OS installer, then why do we have a Software Selection part at all?

I guess on the design side of things, we're looking at changing the radio buttons to check boxes. I don't see any technical or logical reason as to why this change could not be followed.

Sadly, every reply saying why its bad seems to have been a hand waving excuse that  doesn't seem to have a base in logic.

At the very least, I believe this should have more open community discussion vs having the project strong armed into submission.

Comment 17 Máirín Duffy 2012-11-12 19:19:49 UTC
Hi Steven,

"Sadly, every reply saying why its bad seems to have been a hand waving excuse that  doesn't seem to have a base in logic."

Just because the folks who have been working on this over the past two years are explaining their reasoning and you don't like the answers doesn't mean they are illogical. If you are confused, please ask questions, don't throw barbs at us telling us that we are just feeding you handwavy excuses. You should be happy that we are trying to engage in a conversation with you, although the longer this goes on, the less productive a use of my time it appears to be because of how you are behaving.

"At the very least, I believe this should have more open community discussion vs having the project strong armed into submission."

All of this development has been done in public! Mockups of most of the screens were posted to planet Fedora multiple times over the past year+! The development mailing list and IRC channel where any discussions between the designers and developers took place are completely public, and all of the git commits with logs are completely public. 

Unfair accusations does not a useful discussion make, my friend.

Comment 18 Máirín Duffy 2012-11-12 19:22:37 UTC
Hi Andre,

"'the installer shouldn't go out of its way to make difficult something that's easy after the install.'"

We don't go out of our way to make anything difficult that should be possible in the installer. Our goal is to get you to a minimum working environment to customize to your heart's content. I do not understand how having more than one desktop environment is equivalent to 'minimum working environment' or why you cannot install additional desktop environments post-install, could you please help me understand where the problem is?

Comment 19 Andre Robatino 2012-11-12 19:51:04 UTC
Filed bug 875916 for the missing DEs in the add-ons column when @basic_x is chosen as the DE.

Comment 20 Máirín Duffy 2012-11-12 21:32:01 UTC
Please don't re-open this bug.

Comment 21 Andre Robatino 2012-11-12 22:40:24 UTC
(In reply to comment #19)
> Filed bug 875916 for the missing DEs in the add-ons column when @basic_x is
> chosen as the DE.

Never mind, as I suspected, from https://bugzilla.redhat.com/show_bug.cgi?id=875916#c1 the ability to install multiple DEs via @basic_x was an unintended loophole in the enforcement of one-DE-only which is about to be closed (along with the bug) by removing the DEs from the add-ons list. That explains why none of the devs mentioned it.

Comment 22 satellitgo 2012-11-13 06:19:54 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=876032
 Use USB stick containing kickstart.file for anaconda install
so can use .ks generated by install multiple times

Comment 23 Adam Williamson 2012-11-14 01:15:13 UTC
Mo: the 'why didn't you complain about this earlier?!' line doesn't work very well for this bug, since people have been complaining about it virtually since the first Alpha TCs hit test@.

I _still_ don't see any very convincing reasoning for this, to be quite honest. The closest that anyone's come is "Anaconda is an OS installer. It has installed your OS. It has done all the _necessary_ configuration. You are free after installing the OS to customize it to whatever extent pleases you most." in comment #11, but that's really pretty shoddy. As Steven points out in https://bugzilla.redhat.com/show_bug.cgi?id=875433#c16 , it really doesn't hold up at all. To expand on his points, the obvious answer is that we have a Software Selection screen because 'an OS' is different things to different people. So why is it correct _as a design decision_ to accommodate those for whom 'an OS' is 'a set of packages comprising any one of six different desktops', but not those for whom 'an OS' is 'a set of packages comprising two or more of the six different available desktops'? What is the design basis for the line being drawn there?

Comment 24 Andre Robatino 2012-11-14 02:44:47 UTC
Just to expand on what Adam said, "those" should refer to the whole set of users, not just one. As I argued in https://bugzilla.redhat.com/show_bug.cgi?id=875916#c4 , it's a multiuser OS, and each user in general needs a different set of packages (for example, if they use different desktops) so you need at least the union of all those.

Comment 25 Máirín Duffy 2012-11-14 17:41:32 UTC
If you want to discuss this matter with me you can talk to me about it off of bugzilla. Thanks.

Comment 26 David Lehman 2012-11-14 18:00:39 UTC
(In reply to comment #16)
> Sorry, with all respect David... Where do we draw the line on this?

Since you asked, we draw the line right where we already drew it. You're not happy with it, but there it is.

> I guess on the design side of things, we're looking at changing the radio
> buttons to check boxes. I don't see any technical or logical reason as to
> why this change could not be followed.

I'm not sure when it was decided that anaconda is henceforth going to be designed by a committee of the entire fedora user base. In fact, I don't think it was.

> 
> Sadly, every reply saying why its bad seems to have been a hand waving
> excuse that  doesn't seem to have a base in logic.

We made a design decision to allow a certain set of options during interactive install. Your logic of "but I want this other thing, too" is no more reasonable than any of the "hand waving" that has been done by me.

> 
> At the very least, I believe this should have more open community discussion
> vs having the project strong armed into submission.

You're in real danger of getting ignored permanently with these ridiculous characterizations. The only thing you've been strong armed into is using one of two perfectly viable workarounds.

Comment 27 Adam Williamson 2012-11-14 23:21:00 UTC
Mo: for the public record - I completely misread your comment (17), you weren't saying what I thought you were saying at all, and I'm sorry about that, entirely my fault. I somehow read you as saying that people were complaining too late when that was not what you were saying at all, you were just responding to Steven's suggestion that this had all been done in sekrit. Entirely my fault, I'm sorry.

On that point I think you're right and this has certainly been done perfectly publicly. I'm still not sure I understand the reasoning behind the design or agree with it, but we've been around that rodeo enough times and there's no point doing it any more, and I don't have any complaints at all about the process by which the design was reached. Sorry that I messed that one up.

Comment 28 Peter Robinson 2012-11-15 06:47:08 UTC
(In reply to comment #27)
> Mo: for the public record - I completely misread your comment (17), you
> weren't saying what I thought you were saying at all, and I'm sorry about
> that, entirely my fault. I somehow read you as saying that people were
> complaining too late when that was not what you were saying at all, you were
> just responding to Steven's suggestion that this had all been done in
> sekrit. Entirely my fault, I'm sorry.
> 
> On that point I think you're right and this has certainly been done
> perfectly publicly. I'm still not sure I understand the reasoning behind the
> design or agree with it, but we've been around that rodeo enough times and
> there's no point doing it any more, and I don't have any complaints at all
> about the process by which the design was reached. Sorry that I messed that
> one up.

Just to confirm here that from the Sugar side I was certainly involved in a discussion that was public (I don't remember the forum it could have been lists, FUDCon or somewhere else like IRC) about it and while I took a while to convince I agree it's not a major problem for Sugar. People either tend to use kickstarts or happily install it post install. People have to do it post install anyway for an install from a live image which is the way most people tend to install anyway I believe and they seem to cope with that.

Comment 29 Adam Williamson 2013-01-12 01:11:52 UTC
*** Bug 894332 has been marked as a duplicate of this bug. ***

Comment 30 Leslie Satenstein 2013-01-12 15:01:43 UTC
Try as I may, After installing Gnome, I was absolutely not able to install KDE, even though I installed everything via  yum install *KDE* and *kde*.

Is there anything in the release notes?

I tried putting up a second fedora18 with KDE, but grub does not recognize the former with Gnome.

Comment 31 Steve Tyler 2013-01-13 05:00:20 UTC
To install KDE from the command line:

# yum group install kde-desktop-environment

The yum man page has more info about the yum group command.

After installing Gnome from the DVD and updating, I installed KDE without any problems. The gdm session menu lets you choose:
GNOME
KDE Plasma Workspace
KDE Plasma Workspace (failsafe session)

Tested with:
$ qemu-kvm -m 2048 -hda f18-test-1.img -cdrom ~/xfr/fedora/F18/F18-Final/RC4/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice mouse

Comment 32 Steve Tyler 2013-01-13 05:18:47 UTC
(In reply to comment #30)
...
> I tried putting up a second fedora18 with KDE, but grub does not recognize
> the former with Gnome.

If you installed to different partitions (including boot), this could be a bug.

Comment 33 Chris Lumens 2013-01-29 14:46:04 UTC
*** Bug 905306 has been marked as a duplicate of this bug. ***

Comment 34 Nandan Bhat 2013-01-30 01:38:52 UTC
If we consider the reason for a DVD iso download, it would normally be to have a wider choice of software at install time, compared with the spins.

The default repository configuration is for internet. If network issues prevent access, the user has to manually configure a DVD repository. Not all users instinctively understand preparation of yum configuration. And assuming that a user should make a kickstart for install will mean a better understanding of the release before install itself.

If @basic-x selection at install time allows custom selection of multiple DEs, it can be made the default selection. I am yet to try this, though.

If you see the reason for widespread criticism of Ubuntu/Unity, it is because of default design choices that do not necessarily sit well with old-timers. We tend to feel something being thrust down our throats. An auto-selection followed by an ability to customize everything (as in SUSE) might be better.

However, this is now classified as NOTABUG, so I guess I will have to search the forum where such feedback is acceptable.

Comment 35 Steve Tyler 2013-01-30 04:30:09 UTC
Nandan: I have read your comments here and in Bug 905306, and I still cannot understand what you are trying to accomplish.

If you want to minimize your download for a one-time install, you would be better off downloading the network install CD[1], installing one desktop environment, and then installing additional desktop environments from the installed system.

If you are trying to support multiple users who want to install a variety of configurations, you may need to set up a mirror ...

[1] The x86_64 network install CD is only 294MB:
https://fedoraproject.org/en/get-fedora-options#formats

Comment 36 Andre Robatino 2013-01-30 05:01:47 UTC
Actually, the way to minimize downloading is to get one's hands on a DVD without downloading it (either by mail or being handed a copy from someone local) and then to use as many packages as possible from the media (even if they're old) and then update them using yum-presto. The second step is the one that is being made difficult (and will get even more so in F19, if the DVD install defaults to downloading updates rather than using the original packages on the media).

Comment 37 Máirín Duffy 2013-01-30 21:07:44 UTC
"The second step is the one that is being made difficult (and will get even more so in F19, if the DVD install defaults to downloading updates rather than using the original packages on the media)."

PackageKit is *supposed* to allow you to use the DVD as a repository post-install. This worked in earlier versions of Fedora but has since broken. There's an open bug on that. Our intention here was not to prevent folks without network connections from installing multiple desktops - they should be able to, and they should be able to at any point in time they'd like. Having multiple-desktop selection available in the installer will not solve that for them, because you will have to know ahead of time all the desktops you'd want to install. Plus, if you're in a situation where you don't have internet, you may more likely not have enough disk space to install every desktop available either, so if you make the wrong choice, that would totally suck.

So you seem to be upset about a bug that is not an anaconda bug. I'm sorry i don't have the bug # handy, I think it's against packagekit in the upstream bugzilla.gnome.org tracker.

Comment 38 Andre Robatino 2013-01-30 23:11:15 UTC
(In reply to comment #37)
> "The second step is the one that is being made difficult (and will get even
> more so in F19, if the DVD install defaults to downloading updates rather
> than using the original packages on the media)."
> 
> PackageKit is *supposed* to allow you to use the DVD as a repository
> post-install. This worked in earlier versions of Fedora but has since
> broken. There's an open bug on that. Our intention here was not to prevent
> folks without network connections from installing multiple desktops - they
> should be able to, and they should be able to at any point in time they'd
> like. Having multiple-desktop selection available in the installer will not
> solve that for them, because you will have to know ahead of time all the
> desktops you'd want to install.

If the intent is not to discourage it, why not allow it in the GUI install, like it used to be, using DE check boxes instead of radio buttons? AIUI, the dependency resolving code is already there (it must be, since multiple DE selection is possible with kickstart), so there is no code simplification from NOT doing it (but correct me if I'm wrong) so why not? It doesn't stop anyone from adding even more DEs later.

> Plus, if you're in a situation where you
> don't have internet, you may more likely not have enough disk space to
> install every desktop available either, so if you make the wrong choice,
> that would totally suck.

I don't think that's likely at all. Disk space is a trivial expense compared to bandwidth (especially since the latter is a recurring charge) and it's available regardless of location. In any case, the installer should check that there's enough space for the selected packages.

> So you seem to be upset about a bug that is not an anaconda bug. I'm sorry i
> don't have the bug # handy, I think it's against packagekit in the upstream
> bugzilla.gnome.org tracker.

It's bug 888307 which I am already subscribed to (and made several comments in).

Comment 39 Dan Mashal 2013-01-30 23:17:53 UTC
Mo,

So will the original title of this bug be fixed in F19 Anaconda?

That's what I was under the impression of.

Dan

Comment 40 Máirín Duffy 2013-01-30 23:44:02 UTC
Andre,

"If the intent is not to discourage it"

I never said that. What I said is that the intent was not to negatively impact users who only have access to the DVD and no network to install additional packages. We want to discourage fine-grained software selection in the installer because it is very prone to running into error conditions (what happens if you choose two packages that are conflicts). A fully installed OS is the appropriate place to make fine-grained software selections and to do installation. The point of anaconda is to get you a base OS.

Comment 41 Máirín Duffy 2013-01-30 23:44:20 UTC
Dan, this is not a bug. Thus, it is CLOSED NOTABUG.

Comment 42 Nandan Bhat 2013-01-31 01:36:18 UTC
(In reply to comment #35)
> Nandan: I have read your comments here and in Bug 905306, and I still cannot
> understand what you are trying to accomplish.
> 
> If you want to minimize your download for a one-time install, you would be
> better off downloading the network install CD[1], installing one desktop
> environment, and then installing additional desktop environments from the
> installed system.
> 
> If you are trying to support multiple users who want to install a variety of
> configurations, you may need to set up a mirror ...
> 
> [1] The x86_64 network install CD is only 294MB:
> https://fedoraproject.org/en/get-fedora-options#formats

Steve,

The reason to download the DVD image is to be able to install more packages during install time. Download location need not be at the same place as the install (since install pc may not have a high-speed internet). This means only some packages may be additionally needed after install is completed. For me, the DVD image download takes an entire night to download on a 1 Mbps connection; and that is considered as a fast connection by many here.

If we go with a premise of getting a base system only, any spin would be sufficient - probably LXDE since it will be the smallest image.

Getting the install machine back to working state quickly is also a consideration. Only / area is formatted during install; /home remains untouched. This means installed machine needs to be ready to go after install - with same browser (firefox), same email client (thunderbird) etc.  LXDE does not have firefox, so that will become another download. 

My login is to openbox, not GNOME, KDE etc. So, if I go with GNOME/KDE/LXDE/XFCE, I will still get a warning at login saying my DE is not available and that I should choose from one of the available ones. I like to use KDM. This brings in KDE. I would like to remove most of the media and graphics related stuff KDE has since I won't use them. I also like to see what other DEs are up to occasionally. So, I don't mind installing all of the DEs available (still not trying Sugar though).

I am sensing that the DVD image is getting discouraged and will get discontinued at some point - hence the changes.

Comment 43 Máirín Duffy 2013-01-31 05:29:42 UTC
"If we go with a premise of getting a base system only, any spin would be sufficient - probably LXDE since it will be the smallest image."

For those less fortunate and in a no-network situation, no, a spin would not be sufficient, because most of the spins are CD size or just a little bit more, and the DVD is multiple GB of packages. There is no reason why someone should only be able to make use of those packages at install time, and insisting that they make all package installation decisions at a single point in time rather than being able to try new packages over the course of their using and enjoying the fully-installed OS is rather restrictive, don't you think?

"Getting the install machine back to working state quickly is also a consideration. Only / area is formatted during install; /home remains untouched. This means installed machine needs to be ready to go after install - with same browser (firefox), same email client (thunderbird) etc.  "

yum install firefox thunderbird -y

"My login is to openbox, not GNOME, KDE etc. So, if I go with GNOME/KDE/LXDE/XFCE, I will still get a warning at login saying my DE is not available and that I should choose from one of the available ones. I like to use KDM. This brings in KDE. "

A lot of the KDE packages are packaged that way. If you want to use KDM without the rest (I'm not sure if that's possible) please file another bug against that package. 

"I also like to see what other DEs are up to occasionally. So, I don't mind installing all of the DEs available (still not trying Sugar though)."

yum groupinstall Xfce LXDE "KDE Plasma Workspaces" "GNOME Desktop Environment" "MATE Desktop" "Cinnamon Desktop" -y

"I am sensing that the DVD image is getting discouraged and will get discontinued at some point - hence the changes."

No.

Comment 44 Dan Mashal 2013-01-31 05:53:26 UTC
Might as well get discontinued in favor of live images.

Comment 45 Dan Mashal 2013-01-31 05:55:05 UTC
(In reply to comment #41)
> Dan, this is not a bug. Thus, it is CLOSED NOTABUG.

I'll be more than happy to reopen it and file it as an F19 blocker.

Comment 46 Dan Mashal 2013-01-31 06:07:06 UTC
(In reply to comment #11)
> What is so hard about launching the graphical software installation tool
> after installation and installing all twenty DEs if you so desire?
> 
> Anaconda is an OS installer. It has installed your OS. It has done all the
> _necessary_ configuration. You are free after installing the OS to customize
> it to whatever extent pleases you most.

Can you please elaborate? Because Anaconda 17 can do this.

Comment 47 Andre Robatino 2013-01-31 06:44:31 UTC
(In reply to comment #43)

> For those less fortunate and in a no-network situation, no, a spin would not
> be sufficient, because most of the spins are CD size or just a little bit
> more, and the DVD is multiple GB of packages. There is no reason why someone
> should only be able to make use of those packages at install time, and
> insisting that they make all package installation decisions at a single
> point in time rather than being able to try new packages over the course of
> their using and enjoying the fully-installed OS is rather restrictive, don't
> you think?

Straw man, unless you can give an example of someone who actually proposed that people shouldn't be allowed to install extra packages on an already installed system. Certainly not me ("It doesn't stop anyone from adding even more DEs later." from comment 38).

Comment 48 Máirín Duffy 2013-01-31 14:48:45 UTC
"Straw man, unless you can give an example of someone who actually proposed that people shouldn't be allowed to install extra packages on an already installed system. Certainly not me ("It doesn't stop anyone from adding even more DEs later." from comment 38)."

Here's the thing. If you really care about folks in no-network situations, it's better for them to be able to use the DVD packages post-install whenever they want. So I'm trying to point out that saying pulling it from the installer hurts those folks is rather silly, because what hurts them more is the bug that makes them unable to install packages post-install any time at all. 

I never said that anyone said that they shouldn't be able to install post-install. Rather I'm trying to make the point that if you really, truly care about these people, you'd be posting comment after comment on the packagekit bug that disables them from doing so, *not this bug*

Dan, please don't. It would be beyond unhelpful for you to do that.

Comment 49 Steve Tyler 2013-01-31 17:22:14 UTC
(In reply to comment #42)
...
Thanks, Nandan. IIUC, you have two install scenarios:

1. A client with a low-speed network connection who requires one desktop environment and a few additional packages.

2. Yourself. You want to try a variety of desktop environments and do extensive customization.

How does your client with the low-speed network connection get updates?

...
> I am sensing that the DVD image is getting discouraged and will get
> discontinued at some point - hence the changes.

The Fedora DVD is basically bloatware -- users should be able to select what they want to put on their DVD _before_ downloading, so they don't have to download a lot of packages they don't want.

BTW, the F18 LXDE Live spin has firefox, but not thunderbird (a 40 MB download). The F18 LXDE Live spin has the sylpheed email app. Tested with:

$ qemu-kvm -m 2048 -hda f18-test-2.img -cdrom ~/xfr/fedora/F18/F18-Final/Final/Fedora-18-x86_64-Live-LXDE.iso -vga qxl -boot menu=on -usbdevice mouse

Comment 50 Andre Robatino 2013-01-31 18:13:17 UTC
(In reply to comment #49)

> The Fedora DVD is basically bloatware -- users should be able to select what
> they want to put on their DVD _before_ downloading, so they don't have to
> download a lot of packages they don't want.

Again, you're assuming that everyone has to *download* the DVD. The DVD (and the stable lives and spins) are widely used standard images, so it's fairly easy for people with poor or no network to get a physical copy without downloading, if needed. In this case, the size of the image doesn't matter, as long as their hardware can read it. Also, the media cost for single-layer DVD vs. CD is about the same. I suppose someone could sell custom images, but it would cost more, and since a physically obtained image involves no downloading either way, no bandwidth would be saved.

Also, someone may want to be able to do multiple installs, and even if they download, it's only done once, so the size wouldn't matter too much.

(Of course, the question of whether it makes sense to have the DVD is getting off topic, but I think it does.)

Comment 51 Andre Robatino 2013-01-31 18:34:05 UTC
(In reply to comment #48)

> Here's the thing. If you really care about folks in no-network situations,
> it's better for them to be able to use the DVD packages post-install
> whenever they want. So I'm trying to point out that saying pulling it from
> the installer hurts those folks is rather silly, because what hurts them
> more is the bug that makes them unable to install packages post-install any
> time at all.

I'm not qualified to judge in general how dangerous it is to allow multiple DE installs, except my own experience with installing Gnome/KDE in F17 and below, for many years. I never had a problem. I also don't remember hearing of anyone else having such problems, and even if it was significant, a warning pop-up upon selecting more than one check box would suffice (and if the install failed, one could just redo it with only one box checked). OldUI never bothered to do that. Presumably you're talking about errors that would cause the install to fail *after* clicking the "begin installation" button, since newUI doesn't touch anything before that (and I think that's a big improvement over oldUI, BTW). Can you give examples of such errors? Are they bugs in the installer itself, or in the packages involved? If the former, it's in your power to fix them, if the latter, it's not the installer's fault at all and IMHO making multiple DE installs more difficult just sweeps those bugs under the rug.

Also, if check boxes *were* used for the DEs, wouldn't doing a single install with all DE and customization boxes simultaneously checked suffice to expose any such problems with the packages on the DVD? In that case, QA to prevent it would be easy.

> I never said that anyone said that they shouldn't be able to install
> post-install. Rather I'm trying to make the point that if you really, truly
> care about these people, you'd be posting comment after comment on the
> packagekit bug that disables them from doing so, *not this bug*

I did. :)

Comment 52 satellitgo 2013-01-31 18:37:22 UTC
The DVD would make sense if it could be used as a repo for yum for additional installs when the DVD. or dd to USB, is inserted (as it did in previous fedora releases.) Especially if network is not available)

Comment 53 Adam Williamson 2013-01-31 19:03:39 UTC
satellit: this has already been covered above. https://bugzilla.redhat.com/show_bug.cgi?id=875433#c37 . The bug report is https://bugzilla.redhat.com/show_bug.cgi?id=888307 .

Comment 54 Máirín Duffy 2013-01-31 20:05:30 UTC
"I'm not qualified to judge in general how dangerous it is to allow multiple DE installs, except my own experience with installing Gnome/KDE in F17 and below, for many years. I never had a problem. I also don't remember hearing of anyone else having such problems, and even if it was significant, a warning pop-up upon selecting more than one check box would suffice (and if the install failed, one could just redo it with only one box checked)."

Forcing users to redo the entire install because they checked off more than one desktop is completely unacceptable in terms of user experience. I don't think anyone here has said it's dangerous - rather - the price as you've already explained is quite high - if there's an error condition between any two of the selected desktops, it kills the *entire* install. If such a problem exists post-install, it is no big deal, because yum will fail out of the transaction and your machine will be unaffected. A fully-working desktop environment is a much better place from which to do things such as choose multiple desktops and complete individual package-by-package selection and installation, as you have at your fingertips a browser and a reliable network connection from which to research the choices and you can experiment and run test transactions without risking the system.

"Presumably you're talking about errors that would cause the install to fail *after* clicking the "begin installation" button, since newUI doesn't touch anything before that (and I think that's a big improvement over oldUI, BTW). "

Yes, the kind of errors that could happen - say Cinnamon or MATE, essentially being GNOME forks IIUC, have a forked version of a GNOME library that conflicts with the same library in GNOME and you've elected to install both. I think one of the first steps (and one of the devs could probably illustrate this more authoritatively than me) the installer does after 'Begin Installation' is to do a sanity check on the dependency tree of all of the packages queued for installation. You fail the dep check, basically the whole installer has to bail out. We don't ask you which one we prefer over the other because I'm pretty sure we technically don't have a way to figure out if you care about lib-blahblahblah causing the problem or the bigger package group it's a part of to ask the user if they'd like to simply drop either cinnamon or gnome - I think at that part of the process we can only look at stuff at a package level. Someone deeply familiar with the code is a better person to ask though, but I know these types of bugs happen, I have personally experienced them in multi-desktop Fedora installs in the past in the old installer.

"If the former, it's in your power to fix them,"

No, sadly the Anaconda team does not maintain RPM and the problem seems too sticky for the minor convenience of a small minority of users who can't pull up their big boy or girl pants and wait a whole 5 minutes to install other desktops. I'd rather the installer devs work on cool new innovative features to be quite honest - it's a better use of their time.

"if the latter, it's not the installer's fault at all"

It doesn't matter whose fault it is. Does the user know whose fault it is? No. They will blame Fedora in general. And it's very likely a packaging error could cause an issue with the installer. In the beta of F18 there was a bug in how inkscape (of all things!) was packaged that was causing installations to completely fail and bail out. Packaging errors happen though, and we need to treat them as a reality and not design for a perfect world. This is a community project, we have many community volunteers who package stuff for us in their spare time and not a whole lot of QA resources to catch issues like that before they affect everybody. A software design that relies on a perfect world is at best non-resilient and typically a pretty crappy one.

"Also, if check boxes *were* used for the DEs, wouldn't doing a single install with all DE and customization boxes simultaneously checked suffice to expose any such problems with the packages on the DVD? In that case, QA to prevent it would be easy."

No, not at all. The more combinations and test cases you add to a piece of software, especially as huge as Fedora, especially with as few QA resources as Fedora, the more of a maintenance nightmare create and burden you put on the developers. Please, no.


Can we please let this bug die? It is closed. I'm getting really tired of this.

Comment 55 Nandan Bhat 2013-02-01 01:48:39 UTC
(In reply to comment #49)
> (In reply to comment #42)
> ...
> Thanks, Nandan. IIUC, you have two install scenarios:
> 
> 1. A client with a low-speed network connection who requires one desktop
> environment and a few additional packages.
> 
> 2. Yourself. You want to try a variety of desktop environments and do
> extensive customization.
> 
> How does your client with the low-speed network connection get updates?
> 

Both are my machines. A home desktop and a laptop. I don't update packages. I just wait 6+ months for a new release and clean out / at that time. Not a good idea, I know, but I won't be spending time or bandwidth to keep updating all the time.


> ...
> > I am sensing that the DVD image is getting discouraged and will get
> > discontinued at some point - hence the changes.
> 
> The Fedora DVD is basically bloatware -- users should be able to select what
> they want to put on their DVD _before_ downloading, so they don't have to
> download a lot of packages they don't want.
> 

Bloatware it may be, but a single disc is easy for me to use on two machines without any extra configuration (yum).


> BTW, the F18 LXDE Live spin has firefox, but not thunderbird (a 40 MB
> download). The F18 LXDE Live spin has the sylpheed email app. Tested with:
> 

I have not tried to figure out all the differences between the DVD and live images. But a bigger image (more packages) gives me more customization possibility during install. Most people might not download the DVD image seeing the size of the image. But those of us who like customizing the install would much rather prefer the DVD image. Setting up local mirror is more work than using the same DVD across all machines.

> $ qemu-kvm -m 2048 -hda f18-test-2.img -cdrom
> ~/xfr/fedora/F18/F18-Final/Final/Fedora-18-x86_64-Live-LXDE.iso -vga qxl
> -boot menu=on -usbdevice mouse

Comment 56 Nandan Bhat 2013-02-01 01:59:22 UTC
(In reply to comment #54)
> "I'm not qualified to judge in general how dangerous it is to allow multiple
> DE installs, except my own experience with installing Gnome/KDE in F17 and
> below, for many years. I never had a problem. I also don't remember hearing
> of anyone else having such problems, and even if it was significant, a
> warning pop-up upon selecting more than one check box would suffice (and if
> the install failed, one could just redo it with only one box checked)."
> 
> Forcing users to redo the entire install because they checked off more than
> one desktop is completely unacceptable in terms of user experience. I don't
> think anyone here has said it's dangerous - rather - the price as you've
> already explained is quite high - if there's an error condition between any
> two of the selected desktops, it kills the *entire* install. If such a
> problem exists post-install, it is no big deal, because yum will fail out of
> the transaction and your machine will be unaffected. A fully-working desktop
> environment is a much better place from which to do things such as choose
> multiple desktops and complete individual package-by-package selection and
> installation, as you have at your fingertips a browser and a reliable
> network connection from which to research the choices and you can experiment
> and run test transactions without risking the system.
> 
> "Presumably you're talking about errors that would cause the install to fail
> *after* clicking the "begin installation" button, since newUI doesn't touch
> anything before that (and I think that's a big improvement over oldUI, BTW).
> "
> 
> Yes, the kind of errors that could happen - say Cinnamon or MATE,
> essentially being GNOME forks IIUC, have a forked version of a GNOME library
> that conflicts with the same library in GNOME and you've elected to install
> both. I think one of the first steps (and one of the devs could probably
> illustrate this more authoritatively than me) the installer does after
> 'Begin Installation' is to do a sanity check on the dependency tree of all
> of the packages queued for installation. You fail the dep check, basically
> the whole installer has to bail out. We don't ask you which one we prefer
> over the other because I'm pretty sure we technically don't have a way to
> figure out if you care about lib-blahblahblah causing the problem or the
> bigger package group it's a part of to ask the user if they'd like to simply
> drop either cinnamon or gnome - I think at that part of the process we can
> only look at stuff at a package level. Someone deeply familiar with the code
> is a better person to ask though, but I know these types of bugs happen, I
> have personally experienced them in multi-desktop Fedora installs in the
> past in the old installer.
> 
> "If the former, it's in your power to fix them,"
> 
> No, sadly the Anaconda team does not maintain RPM and the problem seems too
> sticky for the minor convenience of a small minority of users who can't pull
> up their big boy or girl pants and wait a whole 5 minutes to install other
> desktops. I'd rather the installer devs work on cool new innovative features
> to be quite honest - it's a better use of their time.
> 
> "if the latter, it's not the installer's fault at all"
> 
> It doesn't matter whose fault it is. Does the user know whose fault it is?
> No. They will blame Fedora in general. And it's very likely a packaging
> error could cause an issue with the installer. In the beta of F18 there was
> a bug in how inkscape (of all things!) was packaged that was causing
> installations to completely fail and bail out. Packaging errors happen
> though, and we need to treat them as a reality and not design for a perfect
> world. This is a community project, we have many community volunteers who
> package stuff for us in their spare time and not a whole lot of QA resources
> to catch issues like that before they affect everybody. A software design
> that relies on a perfect world is at best non-resilient and typically a
> pretty crappy one.
> 
> "Also, if check boxes *were* used for the DEs, wouldn't doing a single
> install with all DE and customization boxes simultaneously checked suffice
> to expose any such problems with the packages on the DVD? In that case, QA
> to prevent it would be easy."
> 
> No, not at all. The more combinations and test cases you add to a piece of
> software, especially as huge as Fedora, especially with as few QA resources
> as Fedora, the more of a maintenance nightmare create and burden you put on
> the developers. Please, no.
> 

If I remember correctly, old RHEL installer used to have an Install Everything option. In fact, it used to calculate disk space usage before partitioning step. Now, we partition first and then select packages - potentially leading to a failed install due to lack of space.

My point is that those features were available in the same anaconda installer. This is not a new feature request. It is the selection of packages that has made things different.

> 
> Can we please let this bug die? It is closed. I'm getting really tired of
> this.

Sure, it is easy. Just stop replying. But some of us probably see this as a potential place to interact. Therefore the comments. As stated in my first post, I was aware that this is a CLOSED NOTABUG. But that doesn't stop me from airing my views. As long as I see that some people are reading and responding.


I am aware that discussion here does NOT have any impact on anaconda development; all it does is, gets some people who feel the current installer action is a bug, to discuss it.

Comment 57 Adam Williamson 2013-02-01 02:41:54 UTC
"If I remember correctly, old RHEL installer used to have an Install Everything option"

...which was taken out because it's too fragile. Breaks far too much. It's not possible to install everything in the repos, and it's not practical to try and ensure everything on the DVD is parallel installable.

"Now, we partition first and then select packages - potentially leading to a failed install due to lack of space."

Nope. F18 does not require you to do either first. The partitioning spoke takes into account the space required by the package set you currently have chosen, and provides a link to go to the software selection spoke and change the currently-selected set, if you don't have enough free space to install. You can bounce between the two spokes as many times as you like to tweak.

Comment 58 Nandan Bhat 2013-02-03 02:30:30 UTC
(In reply to comment #57)
> "If I remember correctly, old RHEL installer used to have an Install
> Everything option"
> 
> ...which was taken out because it's too fragile. Breaks far too much. It's
> not possible to install everything in the repos, and it's not practical to
> try and ensure everything on the DVD is parallel installable.
> 
> "Now, we partition first and then select packages - potentially leading to a
> failed install due to lack of space."
> 
> Nope. F18 does not require you to do either first. The partitioning spoke
> takes into account the space required by the package set you currently have
> chosen, and provides a link to go to the software selection spoke and change
> the currently-selected set, if you don't have enough free space to install.
> You can bounce between the two spokes as many times as you like to tweak.

I am unsure if its a bug, but on an install attempt, F18 DVD installer crashed with custom partitioning. I gave 2 GB (out of 15 GB available) for / and tried to proceed with LXDE desktop. Installer crashed after partitioning. So, the partitioning logic only seems to look for disk size and not for space on /.

Comment 59 Adam Williamson 2013-02-03 02:57:11 UTC
no, it checks for space in /, but it can't be perfect to the last kB, there are edge cases where the space check passes but it just barely runs out of space. Do you know for sure it crashed because it ran out of space?

Comment 61 Steve Tyler 2013-02-03 04:48:13 UTC
With 2 GB "/", 1 GB "/home", 500 MB swap, I get an alert with this fatal error while installing LXDE with the F18 DVD:

You need more space on the following file systems:
28.97 MB on /

The only button is "Exit Installer".

There used to be a bug for this, but I couldn't find it ...

Tested with:
$ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom ~/xfr/fedora/F18/F18-Final/Final/Fedora-18-x86_64-DVD.iso -vga std -boot menu=on -usbdevice mouse

Comment 62 Steve Tyler 2013-02-03 05:04:47 UTC
(In reply to comment #61)
...
> There used to be a bug for this, but I couldn't find it ...
...

Bug 853636, Comment 45 says it was fixed ...

Comment 63 Nandan Bhat 2013-02-03 05:11:44 UTC
Looks like the discussion is getting away from the title. My point is just to showcase that even with a single DE, it is possible to get a failed install - a poor user experience as was mentioned above.

Is it not better to put auto-selection for new users and leave customization with a caveat emptor warning? This way new users are sure to get a good experience and old-timers get to do exactly what they want.

Comment 64 Steve Tyler 2013-02-03 05:41:03 UTC
Install failures are bugs and should be fixed.

I tried to reproduce the alleged problem with Gnome and MATE by first installing Gnome and then installing MATE from the installed Gnome system using PackageKit. The MATE install succeeded and MATE could be selected as a session from gdm.

The only immediately obvious problem was that while running MATE some apps were listed twice in its menus. In particular, mate-terminal and gnome-terminal could both be selected. gnome-terminal ran, but the text and background were both black.

Comment 65 Andre Robatino 2013-02-03 05:44:21 UTC
(In reply to comment #63)

> Is it not better to put auto-selection for new users and leave customization
> with a caveat emptor warning? This way new users are sure to get a good
> experience and old-timers get to do exactly what they want.

I wouldn't say "sure" (even if they abide by the warning and check only one box), since there are numerous other things like hardware issues that can cause an install to fail, but I agree with you that the warning should be enough.

There was talk of updating kickstart so it could work off a thumb drive during installation. Currently it only works off either the network or a floppy (!). AIUI kickstart lets you use a several-line file specifying just the package selection, so this would be almost competitive with doing it in the GUI, if you could actually use a thumb drive. I don't know what the status is.

https://fedoraproject.org/wiki/Anaconda/Kickstart

Comment 66 Andre Robatino 2013-02-03 05:52:37 UTC
(In reply to comment #65)

> during installation. Currently it only works off either the network or a
> floppy (!).

Sorry, the link says that you can also use a CD-ROM or a local hard drive. But neither of those is ideal, either. The thumb drive would be the easiest method if it worked.

Comment 67 Dan Mashal 2013-02-03 06:24:33 UTC
For the record MATE has been packaged in such a way TO NOT conflict with Gnome. Same goes for cinnamon. Please let me know if I am incorrect.


Thanks.
Dan

Comment 68 Andre Robatino 2013-02-03 06:39:25 UTC
FWIW, the standard install tests require DVD repoclosure and no file conflicts, but allow package conflicts. The 18 Final DVD only has one of those, between libpng-devel-1.5.13-1.fc18 and libpng12-devel-1.2.50-2.fc18. I don't know which combinations of DEs would hit that.

Comment 69 Dan Mashal 2013-02-03 09:50:48 UTC
(In reply to comment #54)
> "I'm not qualified to judge in general how dangerous it is to allow multiple
> DE installs, except my own experience with installing Gnome/KDE in F17 and
> below, for many years. I never had a problem. I also don't remember hearing
> of anyone else having such problems, and even if it was significant, a
> warning pop-up upon selecting more than one check box would suffice (and if
> the install failed, one could just redo it with only one box checked)."
> 
> Forcing users to redo the entire install because they checked off more than
> one desktop is completely unacceptable in terms of user experience. I don't
> think anyone here has said it's dangerous - rather - the price as you've
> already explained is quite high - if there's an error condition between any
> two of the selected desktops, it kills the *entire* install. If such a
> problem exists post-install, it is no big deal, because yum will fail out of
> the transaction and your machine will be unaffected. A fully-working desktop
> environment is a much better place from which to do things such as choose
> multiple desktops and complete individual package-by-package selection and
> installation, as you have at your fingertips a browser and a reliable
> network connection from which to research the choices and you can experiment
> and run test transactions without risking the system.
> 
> "Presumably you're talking about errors that would cause the install to fail
> *after* clicking the "begin installation" button, since newUI doesn't touch
> anything before that (and I think that's a big improvement over oldUI, BTW).
> "
> 
> Yes, the kind of errors that could happen - say Cinnamon or MATE,
> essentially being GNOME forks IIUC, have a forked version of a GNOME library
> that conflicts with the same library in GNOME and you've elected to install
> both. I think one of the first steps (and one of the devs could probably
> illustrate this more authoritatively than me) the installer does after
> 'Begin Installation' is to do a sanity check on the dependency tree of all
> of the packages queued for installation. You fail the dep check, basically
> the whole installer has to bail out. We don't ask you which one we prefer
> over the other because I'm pretty sure we technically don't have a way to
> figure out if you care about lib-blahblahblah causing the problem or the
> bigger package group it's a part of to ask the user if they'd like to simply
> drop either cinnamon or gnome - I think at that part of the process we can
> only look at stuff at a package level. Someone deeply familiar with the code
> is a better person to ask though, but I know these types of bugs happen, I
> have personally experienced them in multi-desktop Fedora installs in the
> past in the old installer.
> 


See comment #67


> "If the former, it's in your power to fix them,"
> 
> No, sadly the Anaconda team does not maintain RPM and the problem seems too
> sticky for the minor convenience of a small minority of users who can't pull
> up their big boy or girl pants and wait a whole 5 minutes to install other
> desktops. I'd rather the installer devs work on cool new innovative features
> to be quite honest - it's a better use of their time.
> 

How did it work in 17?

> 
> It doesn't matter whose fault it is. Does the user know whose fault it is?
> No. They will blame Fedora in general. And it's very likely a packaging
> error could cause an issue with the installer. In the beta of F18 there was
> a bug in how inkscape (of all things!) was packaged that was causing
> installations to completely fail and bail out. Packaging errors happen
> though, and we need to treat them as a reality and not design for a perfect
> world. This is a community project, we have many community volunteers who
> package stuff for us in their spare time and not a whole lot of QA resources
> to catch issues like that before they affect everybody. A software design
> that relies on a perfect world is at best non-resilient and typically a
> pretty crappy one.
> 
> "Also, if check boxes *were* used for the DEs, wouldn't doing a single
> install with all DE and customization boxes simultaneously checked suffice
> to expose any such problems with the packages on the DVD? In that case, QA
> to prevent it would be easy."
>
> No, not at all. The more combinations and test cases you add to a piece of
> software, especially as huge as Fedora, especially with as few QA resources
> as Fedora, the more of a maintenance nightmare create and burden you put on
> the developers. Please, no.
> 
> 
> Can we please let this bug die? It is closed. I'm getting really tired of
> this.

If you're getting tired of it, fix it.

Comment 70 Máirín Duffy 2013-02-04 15:45:22 UTC
> If you're getting tired of it, fix it.

This is not a bug. See status, "CLOSED NOT A BUG"

Please stop.

Comment 71 Adam Williamson 2013-04-19 20:25:12 UTC
Should be either commonbugs or release notes, not both. As it's by design, release notes, not commonbugs.

Comment 72 Chris Lumens 2013-08-21 19:07:43 UTC
*** Bug 995705 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.