Hide Forgot
Description of problem: lyx is non-functional without either lyx-qt or lyx-xforms, so *some* default needs to be chosen for either upgrades or fresh installs if only lyx is specified. Unfortunately the current Requires is not deterministic and can vary whether smart or yum are used. Version-Release number of selected component (if applicable): lyx-1.3.7-5.fc4 How reproducible: Every time Steps to Reproduce: 1. yum install lyx 2. smart install lyx Actual results: Using smart: $ sudo smart install lyx Computing transaction... Installed packages (2): lyx-1.3.7-5.fc4@i386 lyx-xforms-1.3.7-5.fc4@i386 5.8MB of package files are needed. 20.9MB will be used. Confirm changes? (Y/n): n $ sudo yum install lyx --> Populating transaction set with selected packages. Please wait. ---> Package lyx.i386 0:1.3.7-5.fc4 set to be updated --> Running transaction check --> Processing Dependency: lyx-frontend = 1.3.7 for package: lyx --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package lyx-qt.i386 0:1.3.7-5.fc4 set to be updated --> Running transaction check Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: lyx i386 1.3.7-5.fc4 extras 3.9 M Installing for dependencies: lyx-qt i386 1.3.7-5.fc4 extras 1.9 M Transaction Summary ============================================================================= Install 2 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 5.8 M Is this ok [y/N]: Expected results: lyx-qt should always be chosen if only lyx is specified. Obviously if lyx-xforms is explicitly chosen, then only it (and not lyx-qt) should be installed. Additional info: I think the requires should be amended so that lyx-qt is always installed, so that smart will also do the right thing like yum does. It bothers me that the upgrade path is non-deterministic and in this case, just happens to depend on which package manager you are using, it should be under the control of the packager.
The reason I choose lyx-qt as the default is that in most cases, that's the one that uses the most modern toolkit, plus it is the interface that folks have expected from previous releases of lyx. Note that I am *not* suggesting only mandating lyx-qt to be installed. If the user wants lyx-xforms, then they can install it. I'm saying that the principle of least surprise dictates that if a user is upgrading from an older version of the package, they always get the package that has the older interface. Basically all I'm saying is that if only is lyx is specified (either from yum in the command line, or using yumex or) then one of the other backends *has* to be chosen, and it may as well be lyx-qt.
Rex Dieter's comments copied from: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181713#c9 > I'm strongly against forcing any particular front-end on anyone. End users > should be free to choose. Agreed, I'm not trying to force a front-end, but in this case lyx won't function without one, so that one has to be chosen (or both could be!?)
Great, now I'd love to hear how to implement this. (-: As it stands, the 'lyx' core package includes Requires: lyx-frontend = %{version} And both 'lyx-qt' and 'lyx-xforms' include: Provides: lyx-frontend = %{version}-%{release}
(In reply to comment #3) > Great, now I'd love to hear how to implement this. (-: Sorry, dunno. I'm not saying I know how, just saying that's how it *ought* to be ;-) Right now if you use yum (which is the only supported tool of Fedora, AFAIK and probably the tool that most currently use now), you get the behaviour I want anyhow, so I guess it's not such a big deal. I'll think about it. It's a probably in general where a core package can have multiple front-ends and at least one has to be installed, it seems rpm just probably isn't cut out for this kind of thing. It's just strange that smart has a different behaviour (and smart will be coming to FE eventually: bug #175438). Maybe fedora-extras-list will have ideas.
How does maxima handle multiple runtimes?
maxima's implementation is essentially the same as what lyx uses now. maxima includes: Requires: maxima-runtime = %{version} and each individual runtime (clisp, sbcl, etc...) has Provides: maxima-runtime = %{version}-%{release}
So if I just run: yum install maxima what will it do? and what (from a user-perspective) would you expect it to do?
yum pulls in the pkg lowest alphabetically to satisfy Requires: maxima-runtime so it will install maxima-runtime-clisp
Regarding my comment about yum choosing alphabetically... I was wrong. From the FE mailing list(s), it turns out yum chooses the pkg with the shortest name to satisfy dependancies. So, in the case of maxima, maxima-runtime-sbcl ends up being the default. The result is the same for lyx, since lyx-qt is shorter than lyx-xforms. From the rpm mailing lists, it looks like a new tag called (or something like it) Requires(hint) may be coming soon that may help in situations like this.
This will get sorted out when/if we ever get Requires(hint) support from rpm.