While playing with custom repos I noticed that libgcj-devel requires a
file from zlib-devel that isn't explicitly provided. In a mixed x86_86 / i386
environmentment this requires looking at the file lists to see that
libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that
zlib-1.2.3-18.fc9.x86_64 isn't good enough.

I am not sure if this is actually a bug though and if so, which package
is at fault. I was hoping to get some guidance here on whether or not
this is something I should bugzilla.

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Mon, 2008-09-22 at 11:33 -0500, Bruno Wolff III wrote:
> While playing with custom repos I noticed that libgcj-devel requires a
> file from zlib-devel that isn't explicitly provided. In a mixed x86_86 / i386
> environmentment this requires looking at the file lists to see that
> libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that
> zlib-1.2.3-18.fc9.x86_64 isn't good enough.
>
> I am not sure if this is actually a bug though and if so, which package
> is at fault. I was hoping to get some guidance here on whether or not
> this is something I should bugzilla.

I think that file dep is explicit - b/c libgcj-devel-4.3.2-4.i386 needs
the i386 version of that package - not the x86_64.

-sv


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Mon, Sep 22, 2008 at 12:40:10 -0400,
seth vidal <skvidal@fedoraproject.org> wrote:
> On Mon, 2008-09-22 at 11:33 -0500, Bruno Wolff III wrote:
> > While playing with custom repos I noticed that libgcj-devel requires a
> > file from zlib-devel that isn't explicitly provided. In a mixed x86_86 / i386
> > environmentment this requires looking at the file lists to see that
> > libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that
> > zlib-1.2.3-18.fc9.x86_64 isn't good enough.
> >
> > I am not sure if this is actually a bug though and if so, which package
> > is at fault. I was hoping to get some guidance here on whether or not
> > this is something I should bugzilla.
>
> I think that file dep is explicit - b/c libgcj-devel-4.3.2-4.i386 needs
> the i386 version of that package - not the x86_64.

It requires a specific lib file that is different between the i386 and x86_64
versions of zlib-devel. However the different files are not "provide"d by
either zlib so you can't find the dependceny without using the file lists.

There are over 700 -devel rpms in Fedora where the i386 version of the
package doesn't "provide" anything not "provide"d by the x86_64 version.
presumably most of these put their libs in different places and they
get pulled in because yum (or whatever) ends up looking through the file
lists.

(There are also a lot (nearly 3000) of the i386 rpms in fedora that "provide"
something not provided by any x86_64 packages, but are not included in
the normal x86_64 rawhide repo. This seems odd, but not strictly an error.
My supposition is that a lot of these packages have a gratiutious (x86-32)
provides, but I really haven't look into it.)

In a couple of cases I looked at things are even more broken. For example
nspr-devel is needed by nss-devel and there do appear to be differences
between the i386 and x86_64 libraries, yet the requires for nss-devel to not
require anything that is not provided by the x86_64 version of nspr-devel.
I am not 100% sure this is broken, but it looks wrong to me.

[root@cerberus Packages]# rpm -q --provides -p nspr-devel-4.7.1-2.fc10.i386.rpm
nspr-devel = 4.7.1-2.fc10
[root@cerberus Packages]# rpm -q --requires -p nss-devel-3.12.1.1-2.fc10.i386.rpm
/bin/sh
libfreebl3.so
libnss3.so
libnssckbi.so
libnssdbm3.so
libnsspem.so
libnssutil3.so
libsmime3.so
libsoftokn3.so
libssl3.so
nspr-devel >= 4.7
nss = 3.12.1.1-2.fc10
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
[root@cerberus Packages]# rpm -qlp ../../x86_64/Packages/nspr-devel-4.7.1-2.fc10.x86_64.rpm
/usr/bin/nspr-config
/usr/include/nspr4
/usr/include/nspr4/nspr.h
/usr/include/nspr4/obsolete
/usr/include/nspr4/obsolete/pralarm.h
/usr/include/nspr4/obsolete/probslet.h
/usr/include/nspr4/obsolete/protypes.h
/usr/include/nspr4/obsolete/prsem.h
/usr/include/nspr4/plarena.h
/usr/include/nspr4/plarenas.h
/usr/include/nspr4/plbase64.h
/usr/include/nspr4/plerror.h
/usr/include/nspr4/plgetopt.h
/usr/include/nspr4/plhash.h
/usr/include/nspr4/plresolv.h
/usr/include/nspr4/plstr.h
/usr/include/nspr4/pratom.h
/usr/include/nspr4/prbit.h
/usr/include/nspr4/prclist.h
/usr/include/nspr4/prcmon.h
/usr/include/nspr4/prcountr.h
/usr/include/nspr4/prcpucfg.h
/usr/include/nspr4/prcvar.h
/usr/include/nspr4/prdtoa.h
/usr/include/nspr4/prenv.h
/usr/include/nspr4/prerr.h
/usr/include/nspr4/prerror.h
/usr/include/nspr4/prinet.h
/usr/include/nspr4/prinit.h
/usr/include/nspr4/prinrval.h
/usr/include/nspr4/prio.h
/usr/include/nspr4/pripcsem.h
/usr/include/nspr4/private
/usr/include/nspr4/private/pprio.h
/usr/include/nspr4/private/pprthred.h
/usr/include/nspr4/private/prpriv.h
/usr/include/nspr4/prlink.h
/usr/include/nspr4/prlock.h
/usr/include/nspr4/prlog.h
/usr/include/nspr4/prlong.h
/usr/include/nspr4/prmem.h
/usr/include/nspr4/prmon.h
/usr/include/nspr4/prmwait.h
/usr/include/nspr4/prnetdb.h
/usr/include/nspr4/prolock.h
/usr/include/nspr4/prpdce.h
/usr/include/nspr4/prprf.h
/usr/include/nspr4/prproces.h
/usr/include/nspr4/prrng.h
/usr/include/nspr4/prrwlock.h
/usr/include/nspr4/prshm.h
/usr/include/nspr4/prshma.h
/usr/include/nspr4/prsystem.h
/usr/include/nspr4/prthread.h
/usr/include/nspr4/prtime.h
/usr/include/nspr4/prtpool.h
/usr/include/nspr4/prtrace.h
/usr/include/nspr4/prtypes.h
/usr/include/nspr4/prvrsion.h
/usr/include/nspr4/prwin16.h
/usr/lib64/libnspr4.so
/usr/lib64/libplc4.so
/usr/lib64/libplds4.so
/usr/lib64/pkgconfig/nspr.pc

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Mon, 2008-09-22 at 13:26 -0500, Bruno Wolff III wrote:
> On Mon, Sep 22, 2008 at 12:40:10 -0400,
> seth vidal <skvidal@fedoraproject.org> wrote:
> > On Mon, 2008-09-22 at 11:33 -0500, Bruno Wolff III wrote:
> > > While playing with custom repos I noticed that libgcj-devel requires a
> > > file from zlib-devel that isn't explicitly provided. In a mixed x86_86 / i386
> > > environmentment this requires looking at the file lists to see that
> > > libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that
> > > zlib-1.2.3-18.fc9.x86_64 isn't good enough.
> > >
> > > I am not sure if this is actually a bug though and if so, which package
> > > is at fault. I was hoping to get some guidance here on whether or not
> > > this is something I should bugzilla.
> >
> > I think that file dep is explicit - b/c libgcj-devel-4.3.2-4.i386 needs
> > the i386 version of that package - not the x86_64.
>
> It requires a specific lib file that is different between the i386 and x86_64
> versions of zlib-devel. However the different files are not "provide"d by
> either zlib so you can't find the dependceny without using the file lists.
>
> There are over 700 -devel rpms in Fedora where the i386 version of the
> package doesn't "provide" anything not "provide"d by the x86_64 version.
> presumably most of these put their libs in different places and they
> get pulled in because yum (or whatever) ends up looking through the file
> lists.
>

Yes - that's a file dep - that's how they work. I'm not a big fan of
them, either.

If you'd like to lead a crusade to get rid of them I'll happily follow
but seeing as I've tried it twice I'm not going to lead another one

-sv


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Mon, 2008-09-22 at 14:29 -0400, seth vidal wrote:

> If you'd like to lead a crusade to get rid of them I'll happily follow
> but seeing as I've tried it twice I'm not going to lead another one

In this case, wouldn't it be something that we could use the new rpm
isa-provides for?

Requires: zlib-devel(x86-32)

Of course, that doesn't seem to be working right now in rawhide... but I
think all we'd need to do is rebuild zlib.

~spot



--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Mon, 2008-09-22 at 15:27 -0400, Tom "spot" Callaway wrote:
> On Mon, 2008-09-22 at 14:29 -0400, seth vidal wrote:
>
> > If you'd like to lead a crusade to get rid of them I'll happily follow
> > but seeing as I've tried it twice I'm not going to lead another one
>
> In this case, wouldn't it be something that we could use the new rpm
> isa-provides for?
>
> Requires: zlib-devel(x86-32)
>
> Of course, that doesn't seem to be working right now in rawhide... but I
> think all we'd need to do is rebuild zlib.
>

indeed - except we'd have to make that work per-arch b/c zlib-devel
(x86-32) isn't going to work so well on ppc64

-sv


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Mon, Sep 22, 2008 at 14:29:05 -0400,
seth vidal <skvidal@fedoraproject.org> wrote:
>
> Yes - that's a file dep - that's how they work. I'm not a big fan of
> them, either.
>
> If you'd like to lead a crusade to get rid of them I'll happily follow
> but seeing as I've tried it twice I'm not going to lead another one

Right now I am cla only and not in a good position to lead packaging
initiatives. (I want to eventually be a packager, but the code I have a
particular interest in packaging is written in java which I not that
familiar with and needs to have have copyrighted images scrubbed and
will still need to be looked at further because it is based on a boardgame.)

I don't think finding references to files and changing the providing packages
to explicitly provide them would be all that hard. While this would speed
up yum in some cases I am not sure this is really the right approach.
Someone really needs to think about how provides/requires should be used
and how multilib will interact with this. I suspect this wouldn't be a high
priority initiative. The benefits would be faster yum and rpm (since filelist
checks for requirements could be skipped) and perhaps a better way to figure
out which i386 packages should be included in the x86_64 repo.

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Mon, 2008-09-22 at 14:45 -0500, Bruno Wolff III wrote:

> Right now I am cla only and not in a good position to lead packaging
> initiatives. (I want to eventually be a packager, but the code I have a
> particular interest in packaging is written in java which I not that
> familiar with and needs to have have copyrighted images scrubbed and
> will still need to be looked at further because it is based on a boardgame.)
>
> I don't think finding references to files and changing the providing packages
> to explicitly provide them would be all that hard.


Changing the pkgs AFTER the fact?

-sv


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Mon, Sep 22, 2008 at 15:47:51 -0400,
seth vidal <skvidal@fedoraproject.org> wrote:
> On Mon, 2008-09-22 at 14:45 -0500, Bruno Wolff III wrote:
>
> > Right now I am cla only and not in a good position to lead packaging
> > initiatives. (I want to eventually be a packager, but the code I have a
> > particular interest in packaging is written in java which I not that
> > familiar with and needs to have have copyrighted images scrubbed and
> > will still need to be looked at further because it is based on a boardgame.)
> >
> > I don't think finding references to files and changing the providing packages
> > to explicitly provide them would be all that hard.
>
>
> Changing the pkgs AFTER the fact?

This would require new releases. Only the providing packages would need to
be changed to explicitly provide the capability corresponding to the file.
It's a LOT of grunt work, but not hard. This wouldn't break anything.
It doesn't even all need to be done at the same time. It would increase the
list of capabilities a couple of % (based on roughly 50000 capabilities in a
repo and on the order of 1000 packages that likely implicitly provide files as
capabilities). This wouldn't stop people from making new ones. To do that
you'd need to change yum/rpm to not work if they did. That would be a big
change that you'd want to do for a Fedora release.

However, I suspect that putting in all of those provides is something that
the project would want to undo later. (After thinking about about how
it would really be best to do things something other than file names might
end up being used.) So I doubt it is worth the work to do this. (At least
not before long term goals are set.)

If the (x86-32) stuff is relatively automatic it might be worth getting
a list of packages which would take advantage of this and get them
rebuilt. I don't know much about that feature, just waht Spot referred to and
that I saw a lot of capabilities with the string '(x86-32)' in them. Cleaning
up packages to make reference to the x86-32 capabilities might be harder.

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Mon, 22 Sep 2008, seth vidal wrote:


On Mon, 2008-09-22 at 15:27 -0400, Tom "spot" Callaway wrote:

On Mon, 2008-09-22 at 14:29 -0400, seth vidal wrote:


If you'd like to lead a crusade to get rid of them I'll happily follow
but seeing as I've tried it twice I'm not going to lead another one


In this case, wouldn't it be something that we could use the new rpm
isa-provides for?

Requires: zlib-devel(x86-32)

Of course, that doesn't seem to be working right now in rawhide... but I
think all we'd need to do is rebuild zlib.



indeed - except we'd have to make that work per-arch b/c zlib-devel
(x86-32) isn't going to work so well on ppc64


Well obviously you don't want to use literal, hardcoded "Requires:
zlib-devel(x86-32)" in the spec, but this instead:


Requires: zlib-devel%{?_isa}

That gets expanded at build time to the ISA name of the package being
built. And it's backwards compatible in the sense that if built with older
rpm, you get just "Requires: zlib-devel" like before.


And yes this is one of the major cases for which the whole ISA-thingie was
invented. What's missing is the mass-rebuild to make the ISA-provides
globally available, and FPC guidelines on using them.


- Panu -

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging