Bug 128492 – packages in package.provided are not considered for blocks

• Product: Portage Development
• Status: RESOLVED INVALID

[Description Petteri Räty (RETIRED) 2006-04-02 03:37:20 UTC]

To reproduce:
1. put a package to package.provided
2. use emerge -pv on an ebuild that blocks the package you put to package.provided
3. emerge let's you install the blocking package

Solution:
packages in package.provided should be handled like packages installed by Portage

Portage 2.1_pre7-r3 (default-linux/x86/2005.1, gcc-3.4.5, glibc-2.4-r1, 2.6.15-gentoo-r7 i686)
=================================================================
System uname: 2.6.15-gentoo-r7 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz
Gentoo Base System version 1.12.0_pre16
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ccache version 2.4 [enabled]
dev-lang/python:     2.4.2-r1
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-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium4 -pipe -mfpmath=sse -ffast-math -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=pentium4 -pipe -mfpmath=sse -ffast-math -fomit-frame-pointer"
DISTDIR="/usr/src/distfiles"
FEATURES="autoaddcvs autoconfig ccache collision-protect confcache cvs distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict stricter verify-rdepend"
GENTOO_MIRRORS=" http://trumpetti.atm.tut.fi/gentoo  http://lame.lut.fi/linux/gentoo "
LANG="en_US.utf8"
LC_ALL="en_US.utf8"
LINGUAS="fi"
MAKEOPTS="-j2"
PKGDIR="/home/pkg/"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/mnt/checkouts/overlays/betelgeuse /mnt/checkouts/gentooexperimental/gentoo-java-experimental"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 aac acl acpi alsa apm arts audiofile avi bash-completion berkdb bitmap-fonts bluetooth bzip2 bzlib cairo cdb cddb cdparanoia crypt cups dbus divx4linux dri dts dvd dvdr dvdread emboss esd ffmpeg firefox foomaticdb freetype gif gstreamer gtk2 hal isdnlog java jpeg kde kdeenablefinal libg++ libwww logitech-mouse mad makecheck mikmod mjpeg mmx mmx2 mp3 mpeg ncurses network nptl nptlonly nsplugin nvidia offensive ogg oggvorbis opengl pam pdflib png pppd qt quicktime readline real rtc samba spell sse sse2 ssl subversion svg symlink tcpd theora threads truetype truetype-fonts type1-fonts unicode usb userlocales vorbis win32codecs xcomposite xml xml2 xv xvid zlib elibc_glibc input_devices_mouse input_devices_keyboard kernel_linux linguas_fi userland_GNU video_cards_none video_cards_nvidia"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LDFLAGS

[Comment 1 UncleOwen 2006-04-02 03:59:56 UTC]

I'd argue that this is not a bug: Most blockers are there because 2 packages install the same file in the same location. If you install a packages by hand (and put it in package.provided) you usually install it in a different location.

[Comment 2 Jakub Moc (RETIRED) 2006-04-02 04:12:04 UTC]

(In reply to comment #1)
> I'd argue that this is not a bug: Most blockers are there because 2 packages
> install the same file in the same location. If you install a packages by hand
> (and put it in package.provided) you usually install it in a different
> location.

So - you install the packages in other locations so that other ebuilds from portage wouldn't find them? Hmmm. I don't. 

[Comment 3 Simon Stelling (RETIRED) 2006-04-02 05:10:08 UTC]

you can put 'it' (e.g. being a binary or a shared lib) in other locations and it will be found nevertheless, that's what we have PATH and LDPATH for.

[Comment 4 Jakub Moc (RETIRED) 2006-04-02 05:15:59 UTC]

Yeah, you can put 'it' in any location and set PATH and LDPATH accordingly and break the stuff that blocks a particular version of something or blocks even the package completely b/c it breaks when it gets installed at the same time. ;) 

The current behaviour is inconsistent, that's about it. Quick example? cryptsetup/cryptsetup-luks. I'm sure there are quite a few of them.

[Comment 5 Simon Stelling (RETIRED) 2006-04-02 05:17:58 UTC]

i didn't say this isn't a bug - i just said your reasoning sucks :P

[Comment 6 Marius Mauch (RETIRED) 2006-04-03 12:53:34 UTC]

I don't consider this a bug, if you put something in p.provided you take full responsibility for it. You can still use collision-protect to avoid file clashes.
And if p.provided packages would block in-tree packages without any real reason (like using a different prefix) people will get angry.
Basically portage shouldn't act like it knows things it doesn't know (in this case package identity).

[Comment 7 Simon Stelling (RETIRED) 2006-04-15 04:51:33 UTC]

(In reply to comment #6)
> I don't consider this a bug, [...]

hugh, the chief has spoken.