Bugzilla Bug 91490

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 an attachment (id=58141) [edit]
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 an attachment (id=58368) [edit]
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.