Description of problem: texlive conflicts with ht in /usr/bin/ht Version-Release number of selected component (if applicable): texlive-tex4ht-svn29474.0-20.fc18.noarch.rpm ht-2.0.18-3.fc18.i686.rpm Steps to Reproduce: yum install ht texlive-tex4ht-bin Actual results: ... Running Transaction Test Transaction Check Error: file /usr/bin/ht conflicts between attempted installs of ht-2.0.18-3.fc18.i686 and texlive-tex4ht-bin-2:svn26509.0-20.20130321_r29448.fc18.i686 Additional information: In tetex this binary was called t4ht. Probably, texlive should rename it this way?
As discussed in bug#954086 this may impact installation as user can't install all groups in "Add-Ons for Selected Environment" that are for GNOME desktop. So, nominating it Please consider this bug as an Fedora 19 Beta release blocker [1]. It impacts the release criterion that "When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set." and "All Fedora 19 Alpha Release Criteria must be met." [1] https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria P.S. I was unable to find does "release blocking desktops" cover add-ons or not. Probably, release criteria should clarify it.
"P.S. I was unable to find does "release blocking desktops" cover add-ons or not." It is not intended to, no. "Probably, release criteria should clarify it." That's not a bad idea; I'll add it to the explanatory notes for that criterion. The criterion that would be more relevant here, though, is: https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria#No_broken_packages "There must be no errors in any package on the release-blocking images which cause the package to fail to install...Critical errors include, but are not limited to, undeclared conflicts (explicit Conflicts: tags are acceptable) and unresolved dependencies." However, that criterion is explicitly limited to stuff that's on the *media* (i.e. DVD), not in repos. So this doesn't qualify. Anyhow, we either need the two to reconcile their 'ht's, or if they're completely different things have one change its name, or if neither of those is practical for some reason, we *at least* need an explicit Conflicts: tag in the packages.
*** Bug 954086 has been marked as a duplicate of this bug. ***
If the upstream project is hte.sourceforge.net, wouldn't be called hte?
'ht's is completely different things, renaming ht in texlive is very bad because it's a command line tool which many other tex tools call directly, it will break the tools with renaming! As Bill already mentioned above ht (from ht packgage) should be renamed to hte as it's a file editor! and breaks nothing with renaming Reassign to ht component
(In reply to comment #4) > If the upstream project is hte.sourceforge.net, wouldn't be called hte? Well, upstream distributes tarball as ht-*.tar.gz and calling editor as "HT" almost everywhere since ages. Probably it is called "hte.sf.net" because there is (or at least was) no way to rename project at SF.net. There are some other projects there that has domain name differ from how they call themselves. (In reply to comment #5) > As Bill already mentioned above ht (from ht packgage) should be renamed to > hte as it's a file editor! and breaks nothing with renaming With same logic, 'ht' from texlive should be renamed to 'tex4ht' because it's tex tool and point other tools to it. Renaming ht would break at least user experience, who will find some completely unrelated command line tool instead of an editor. Is ht from texlive supposed to be called by user? If not, shouldn't it go to /usr/libexec?
(In reply to comment #5) > renaming ht in texlive is very bad because it's a command line > tool which many other tex tools call directly, > it will break the tools with renaming! And how those tools worked in F-17 when it was called 't4ht'?
Discussed at 2013-05-06 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-06/f19beta-blocker-review-3.2013-05-06-16.02.log.txt . Rejected as a blocker - we only block on conflicts that exist on the physical media. There's no reason to block on conflicts that exist only in the repos, as we can just as easily fix them with an update and holding up the physical media release for them achieves nothing.
I've asked Tex4HT upstream about what do they think about renaming/shipping this script - http://tug.org/pipermail/tex4ht/2013q2/000777.html This is, btw, first thing to do in such cases according to fedora guidelines... And it was very funny to see what this "tool called by many other tex tools" actually is: ================================================================ #!/bin/sh $1 $2 $1 $2 $1 $2 tex4ht $2 t4ht $2 $3 ================================================================
texlive-2013-0.1.20130608_r30832.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/texlive-2013-0.1.20130608_r30832.fc19
texlive-2013-0.1.20130608_r30832.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/texlive-2013-0.1.20130608_r30832.fc18
Package texlive-2013-0.1.20130608_r30832.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing texlive-2013-0.1.20130608_r30832.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-10849/texlive-2013-0.1.20130608_r30832.fc19 then log in and leave karma (feedback).
This change is breaking gnuplot builds due to issues with tex4ht/t4ht. See http://kojipkgs.fedoraproject.org//work/tasks/3830/5553830/build.log
I think ht and t4ht are completely different things (especially since ht calls t4ht).
ht is a link to /usr/share/texlive/texmf-dist/scripts/tex4ht/ht.sh. I could see renaming ht to ht.sh or simply not shipping /usr/bin/ht.
This killed may attempts at a F19 network install. You might want to reconsider the impact on network install. I have no idea which group(s) include the conflict, so as far as I am concerned, network install is dead on F19.
It might help if you specify what groups you tried to install, at least.
The only groups which directly include any texlive packages are 'authoring and publishing' and 'font design'. The texlive dep chains are too complicated for to be willing to suffer the pain of trying to figure out if this is pulled into any other package sets somehow. Frankly, texlive is basically a giant ball of fail in my mind, I avoid it as hard as possible.
(In reply to Adam Williamson from comment #17) > It might help if you specify what groups you tried to install, at least. This is for an EE lab at sjsu. (25 machines). I basically select everything except the medical items. I can try it without authoring and publishing. Students use the machines for a large number of functions, but only a few did their thesis on the lab machines. That worked to get the install started. I can manually add the missing packages after the machine comes up. Thanks, Morris
Thanks, I'll add a commonbug note recommending to avoid that group on network installs for now.
Note that I'm only reverting this at the moment on rawhide. I'd like to get Jindrich's take before messing with F18/F19. But we need to rebuild gnuplot (and dependencies) in rawhide for a soname bump and this change breaks that.
texlive-2013-0.1.20130608_r30832.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
i reopen it again because texlive upstream doesn't want to renaming in texlive. Orion already reverted it in rawhide. The clean/safe solution is to rename ht from ht packgage as i mentioned in comment 5. I think we should revert this change in texlive-2013-0.1.20130608_r30832.fc19 Jindrich, what do you think ?
(In reply to Ngo Than from comment #23) > i reopen it again because texlive upstream doesn't want to renaming in > texlive. Orion already reverted it in rawhide. > > The clean/safe solution is to rename ht from ht packgage as i mentioned in > comment 5. > > I think we should revert this change in texlive-2013-0.1.20130608_r30832.fc19 +1, I just had the rename from ht to t4ht, which turns a htlatex command into a fork bomb, problem bite me while trying to build a new freecol. Can we please revert this, as it is breaking package builds left and right (reported so far are it breaking gnuplot and freecol builds).
I ran into exactly the same issue today on FC18. Please provide an updated package for FC18 as well. Thank you!
(In reply to Hans de Goede from comment #24) > +1, I just had the rename from ht to t4ht, which turns a htlatex command > into a fork bomb, problem bite me while trying to build a new freecol. htlatex fork bombs anyways for example if i run something like this htlatex some.tex tex4ht.c (2012-07-25-19:36 kpathsea) tex4ht --- error --- improper command line tex4ht [-f<path-separator-ch>]in-file[.dvi] [-.<ext>] replacement to default file extension name .dvi [-c<tag name>] choose named segment in env file [-e<env-file>] [-f<path-separator-ch>] remove path from the file name [-F<ch-code>] replacement for missing font characters; 0--255; default 0 [-g<bitmap-file-ext>] [-h(e|f|F|g|s|v|V)] trace: e-errors/warnings, f-htf, F-htf search g-groups, s-specials, v-env, V-env search [-i<htf-font-dir>] [-l<bookkeeping-file>] [-P(*|<filter>)] permission for system calls: *-always, filter [-S<image-script>] [-s<css-file-ext>] default: -s4cs; multiple entries allowed [-t<tfm-font-dir>] [-u10] base 10 for unicode characters [-utf8] utf-8 encoding for unicode characters [-v<idv version>] replacement for the given dvi version [-xs] ms-dos file names for automatically generated gifs and ps -A ... 32744 pts/0 00:00:00 t4ht 32747 pts/0 00:00:00 t4ht 32750 pts/0 00:00:00 t4ht 32753 pts/0 00:00:00 t4ht 32756 pts/0 00:00:00 t4ht 32759 pts/0 00:00:00 t4ht 32762 pts/0 00:00:00 t4ht 32765 pts/0 00:00:00 t4ht ... This shouldn't be the case. And the problem might be elsewhere!
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Just saw this exact same error when trying to install with KDE and with the "documentation" packages. I am using the network install CD for x86_64. It aborted the installer and had to start over. With "documentation" de-selected, seems to be OK on this try (install still in progress).
Forgot to mention that I was attempting to install Fedora 20.
I had this problem a minute ago while I tried to install Fedora 20.
Error message is: Transaction check error: file /usr/bin/ht from install of texlive-tex4ht-bin-3:svn30088.0-4.20131226_r32488.fc20.x86_64 conflicts with file from package ht-2.0.18-5.fc20.x86_64
Any comment or objection from ht maintainers to rename the conflicting binary? (I haven't noticed any yet or please clarify, thanks)
In the meantime I added explicit conflict with ht in texlive-tex4ht.
ht-2.0.18-7.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/ht-2.0.18-7.fc20
ht-2.0.18-7.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/ht-2.0.18-7.fc19
Package ht-2.0.18-7.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ht-2.0.18-7.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7147/ht-2.0.18-7.fc19 then log in and leave karma (feedback).
ht-2.0.18-7.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
ht-2.0.18-7.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.