Just noticed that dev-tex/koma-script collides with app-office/lyx: LyX, a WYSIWYM frontend for LaTeX already comes with koma-script so emerging dev-tex/koma-script _after_ installing LyX will overwrite the files installed by LyX. So they should block each other I think. emerge --info Portage 2.1.1 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 i686) ================================================================= System uname: 2.6.17-gentoo-r8 i686 Pentium III (Coppermine) Gentoo Base System version 1.12.5 Last Sync: Fri, 27 Oct 2006 19:50:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-march=pentium3 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict userfetch userpriv usersandbox" GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LINGUAS="de" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/own /usr/portage/local/layman/ebuild-exchange /usr/portage/local/layman/gentoo-de /usr/portage/local/layman/sunrise /usr/portage/local/layman/musicbrainz" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 X a52 aac alsa asf berkdb bitmap-fonts bzip2 cairo cli cracklib crypt cups dbus dlloader dri dvd elibc_glibc firefox flac fontconfig fortran gd gdbm gif gmp gnome graphviz gs hal imagemagick imlib input_devices_keyboard input_devices_mouse isdnlog jikes jpeg kernel_linux lcms libg++ linguas_de mad mmx mng mp3 mp4 mpeg ncurses nptl nptlonly nsplugin ogg opengl pam pcre perl png postgres ppds python qt3 readline reflection session speex spl sqlite sse ssl svg tcpd theora threads tiff truetype truetype-fonts type1-fonts udev unicode userland_GNU utf8 video_cards_r128 vorbis wmf x264 xface xml xorg xpm xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
???
Heh, forget about the file collision. It is currently impossible to install koma-script. phoenix halcyon # emerge -av koma-script These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-text/texlive-core-2007-r11 USE="X -doc" 42,229 kB [ebuild N ] dev-texlive/texlive-documentation-base-2007 USE="-doc" 1,017 kB [ebuild N ] dev-texlive/texlive-basic-2007 USE="-doc" 29,249 kB [ebuild N ] dev-texlive/texlive-latex-2007 USE="-doc" 29,960 kB [ebuild N ] dev-texlive/texlive-latexrecommended-2007 USE="-doc" 22,731 kB [ebuild N ] virtual/latex-base-1.0 0 kB [ebuild N ] dev-tex/koma-script-20051125 3,544 kB [blocks B ] dev-tex/koma-script (is blocking dev-texlive/texlive-latexrecommended-2007) Tex team: could you please look into both issues here?
Now I see why it was blocked atleast (I should read more before I comment). The first entry in the || dep blocks installing the package that I want. Probably less than ideal behaviour from Portage, but not really a package issue I guess.
(In reply to comment #3) > Now I see why it was blocked atleast (I should read more before I comment). > The first entry in the || dep blocks installing the package that I want. > Probably less than ideal behaviour from Portage, but not really a package issue > I guess. This is because koma-script is included in texlive-latexrecommended from the texlive distribution (note that if I remember correctly, they do not have file collisions but provide the same files in different locations, so it's better to not have them installed at the same time). Perhaps it'd be worth removing it from there and use its own ebuild, but there are a few things that need to be considered: texlive is a tex distribution, it includes thousands of ctan packages; because of this, having one ebuild per ctan package is definitely a no-go the rationale I've tried to keep for having stand alone ebuilds rather than the ones from the distribution are: - the ebuild has to be maintained - having a at-least more up to date package than the one in texlive - being updated more frequently than texlive for now, the koma-script ebuild is only for using with tetex & friends, and if it stays as it is now, it'll probably die with it.
So, should we have them block each other? Make lyx not install its own copy of koma-script? What's the most desirable result here?
(In reply to comment #5) > So, should we have them block each other? Make lyx not install its own copy of > koma-script? What's the most desirable result here? > not sure, our koma-script ebuild is definitely outdated, I dont like apps that ship other packages and prefer having them packaged separately but this often lead to incompatibilities. I think it's better to keep with texlive's packaging of koma-script until tex herd has more manpower. So for now I'd vote for having them block each other (btw, do you have any list of collisions ?), even if that's not the route I prefer going usually.
could you please share the colliding filenames? on my system i see: $ equery files lyx |grep -i koma /usr/share/lyx/fonts/BaKoMaFontLicense.txt /usr/share/lyx/fonts/ReadmeBaKoMa4LyX.txt /usr/share/lyx/templates/koma-letter2.lyx when i look of tex contributed stuff from lyx i see: broadway.cls hollywood.cls lyxchess.sty lyxskak.sty revtex.cls and when i look into my koma-script files: $ cd /usr/share/texmf/tex/latex/koma-script $ equery belongs scrlettr.cls app-text/tetex-3.0_p1-r6 (/usr/share/texmf/tex/latex/koma-script/scrlettr.cls) so from the POV of my box it seems that if theres collision its between tetex ebuild and koma-script ebuild. am i missing something?
Created attachment 141862 [details] koma-script and tetex collisions Yea, with tetex-2.0 installed lyx and koma-script don't have a problem, but koma-script and tetex really hate each other. Its a long list, so I'm attaching it.
aha, i guess that dev-tex/koma-script is intended for tetex-2, and should be blocked in the moment one has tetex-3 as its integral part of tetex-3.
(In reply to comment #9) > aha, i guess that dev-tex/koma-script is intended for tetex-2, and should be > blocked in the moment one has tetex-3 as its integral part of tetex-3. > Please reread my comment. tetex-2 and koma-script hate each other. :) It might have not been clear, but that was the what I meant to communicate.
(In reply to comment #10) > (In reply to comment #9) > > aha, i guess that dev-tex/koma-script is intended for tetex-2, and should be > > blocked in the moment one has tetex-3 as its integral part of tetex-3. > > > > Please reread my comment. tetex-2 and koma-script hate each other. :) It > might have not been clear, but that was the what I meant to communicate. > hu? So to sum it up: - texlive has it and blocks it - koma-script blocks tetex3 because it provides it too - tetex 2 collides with it but does not block it - is ptex fine with it ? I doubt it If ptex collides also with it, that would mean koma-script ebuild is useless with every tex distribution we have. That makes it a good candidate for removal.
(In reply to comment #11) > If ptex collides also with it, that would mean koma-script ebuild is useless > with every tex distribution we have. That makes it a good candidate for > removal. > Punt it, they all collide.
Since you masked it, QA's work here is done. :) Thanks
removed
