Re: conflict/replace/provide
On 20-Feb-99 Josip Rodin wrote:
> On Sat, Feb 20, 1999 at 01:45:15PM -0500, Shaleh wrote:
>> > joy:/usr/src/xpm# dpkg -i libxpm4_3.4j-1_i386.deb
>> > dpkg: considering removing xpm4g in favour of libxpm4 ...
>> > dpkg: no, cannot remove xpm4g (--auto-deconfigure will help):
>> > wmaker depends on xpm4g (>= 3.4j-0)
>> > xpm4g is to be removed.
>> > dpkg: regarding libxpm4_3.4j-1_i386.deb containing libxpm4:
>> > libxpm4 conflicts with xpm4g
>> > xpm4g (version 3.4j-0.6) is installed.
>> > dpkg: error processing libxpm4_3.4j-1_i386.deb (--install):
>> > conflicting packages - not installing libxpm4
>> > Errors were encountered while processing:
>> > libxpm4_3.4j-1_i386.deb
>>
>> Sounds like the ever popular "I need versioned provides".
>
> Why does it have to be *versioned*? It is logical that when you
> depend on some package without version, you depend on every available
> version of that package. It would be normal to presume that if
> you provide some package without, you provide every available version
> of that package, wouldn't it?
>
Would seem so, but there could be a reason why version 0.2.1 was needed rather
than 0.3. Provides will please a package's depends as long as it does not care
about the version.
>> Mind stating why debhelper is stupid? Many packages seem to like it.
>> Suggestions on "fixing" it I am sure would not go on deaf ears.
>
> Would I convert the package to debhelper if I thought that debhelper
> is stupid? :) I just noticed how abnormally dh_installdirs behaves
> in different situations. For example, when called with -plibxpm4 <dir>
> it will not create debian/libxpm4/<dir>, but debian/tmp/<dir>. But,
> a line just after that, when I call it with -plibxpm4-dev <dir>, it
> creates debian/libxpm4-dev/<dir>.
> And when I try that same thing in another target, it will create
> debian/package/<dir>, and wouldn't even think about debian/tmp/.
>
> I've read numerous dh_* manpages (and debhelper(1)) and found no
> exact definition on what it does. And it was easier for me to work
> around the problem than to go investigate in some perl scripts...
>
> However, considering how my whole debian/rules file looks, I'd rather
> say that dh_installdirs is a utility, not a wizard stick :)
Sorry I meant in what ways did it act stupid. I think it has something to do
with the first package it builds versus the other packages. Could be wrong. I
just trusted joeyh's wizardry -- it is easier than worrying about it myself.
Reply to: