On Thu, Apr 12, 2007 at 03:29:09PM +0300, Panu Matilainen wrote:
On Thu, 12 Apr 2007, Axel Thimm wrote:
>On Wed, Apr 11, 2007 at 03:04:54PM -0600, Orion Poplawski wrote:
>>Here's a question. Should -devel package requirements be of the form:
>>
>>Requires: package-devel.%{arch}
>
>Maybe it makes more sense to disallow rpm from satisfying cross-arch
>dependencies at all. noarch belongs to all archs in this
>sense. E.g. in the noarch, i386, x86_64 world, don't allow i386
>packages to satisfy depednencies of x86_64 and vice-versa.
That doesn't quite fly either, it's perfectly valid for a package to
require eg "webclient" for viewing html content and the app doesn't care
if the client is 32bit or 64bit, just as long as it does the job.
I don't see why it couldn't be done in packaging with
something like
"Provides: %{name}.%{_arch} = %{version}-%{release}" in the main package
and "Requires: %{name}.%{_arch} = %{version}-%{release}" in the -devel
package.. or some similar manual construct.
Because ... see your own answer below :)
Whether requiring yet more manual cruft to be added to almost each
and
every package is desirable or feasible is a whole another question :)
Indeed, if we want to solve this it would have to be some solution
that can leave the specfiles at peace. That's why I suggest to change
rpm's interpretation instead of adding new syntax. Maybe the above
isn't the best solution, yet, but perhaps it hints to a better
one. E.g. I'd prefer to come to a solution where only "webclient"
needs special treatment and new syntax, since that would mean touching
a dozen packages and not some thousands :)
But I feel that this is outside the packaging group's domain, we don't
develop rpm. Maybe Orion should file a bug against rpm?
--
Axel.Thimm at
ATrpms.net