Monotone 0.19 released; ebuild for this version should be created. Reproducible: Always Steps to Reproduce: n/a Actual Results: No ebuild available Expected Results: Ebuild should be merged Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r6 i686) ================================================================= System uname: 2.6.11-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 2.66GHz Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Apr 30 2005, 16:26:09)] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /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/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig candy ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.ccccom.com ftp://130.207.108.135/pub/gentoo http://mirror.datapipe.net/gentoo http://open-systems.ufl.edu/mirrors/gentoo ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="x86 X alsa apm arts avi berkdb bitmap-fonts cdr crypt cups curl eds emboss encode esd fam foomaticdb fortran gdbm gif gnome gpm gstreamer gtk2 hal howl imlib ipv6 jpeg libg++ libwww mad mikmod mono motif mozilla mp3 mpeg ncurses nls nptl ogg oggvorbis opengl oss pam pdflib perl png ppds python quicktime readline sdl spell sqlite ssl svga tcpd tetex tiff truetype truetype-fonts type1-fonts usb vorbis xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Created attachment 58141 [details] monotone-0.19.ebuild I've created monotone-0.19.ebuild, which is based on existing 0.18 version. Since 0.19 is fully compatibile with 0.18 and no upgrade process is need I left it in 0.18 slot. It is described by ewarn/einfo in pkg_postinst() section.
Created attachment 58368 [details] monotone-0.19.ebuild multislot version I've upgraded monotone ebuild to use "multislot" flag instead of default slotting because of constant developing progress of that program, so it should be more accurate solution.
I've got the feeling that although a SLOT based USE flag system is something that seems logical, it will break the portage cache and confuse distributions. If you can find another ebuild that uses such a SLOT system I'll investigate it more. If I seem slow to add this I guess I've been a bit busy and waiting for this package to stabilise a bit.
Hello, I've just committed an ebuild for version 0.19. I also set the SLOT back to 0, since slotting is not really a mechanism suited for applications such as monotone. Thanks.
I was inspired by binutils ebuilds, that works that way. I think it is more accurate for monotone, but I have no clear idea.
I understand your point. However, binutils and gcc (the packages implementing 'multislot') are special cases, in that they are actually designed to be installed in parallel with other versions, and there are extraordinary cases where having multiple versions of gcc/binutils actually makes sense. In monotone's case, as I see it, the slotting mechanism was simply a hack intended to provide a migration path, but as it is, just renaming the binaries/docs is unnecessary and non-standard. In my opinion, all of monotone's ebuilds should have SLOT=0 like any regular application, but as we already have some of them with different SLOTS in our tree, we'll have to maintain them for a while. However, please note that it's not my intention to impose my view regarding this matter. I'd be glad to discuss alternatives to improve our ebuilds in any way. So, if you think you still have a good reason to keep using different SLOTs, let me know. Thanks.
No, in fact it was only propsition to consider. Monothone is developed very fast and is still in alpha stage (but usable alpha ;)). So the changes made to it shoult be provided widely as fast as possibile. I thought about multislot as easy and clean solution to migrate, but meybe it shoult be done just by providing einfo/ewarn messages that inform about consequences of merging next release.
