5:02 p.m.
I am getting a multiarch conflict on %doc files in a devel
subpackage[1]. Are we supposed to avoid %doc files in devel packages
for multiarch purposes, or am I doing something wrong in my spec, or
is this a multiarch rpm bug?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=340771
5:07 p.m.
Christopher Stone wrote:
I am getting a multiarch conflict on %doc files in a devel
subpackage[1]. Are we supposed to avoid %doc files in devel packages
for multiarch purposes, or am I doing something wrong in my spec, or
is this a multiarch rpm bug?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=340771
What differs between the files on the 2 arches? Any chance there are
timestamps? Oh, yeah:
"Generated at Wed Jan 31 13:22:54 2007 by ..."
you might want to supress that or filter it out; it'll cause the files
to have different checksums.
-Eric
5:15 p.m.
On 10/19/07, Eric Sandeen <sandeen(a)redhat.com> wrote:
Christopher Stone wrote:
> I am getting a multiarch conflict on %doc files in a devel
> subpackage[1]. Are we supposed to avoid %doc files in devel packages
> for multiarch purposes, or am I doing something wrong in my spec, or
> is this a multiarch rpm bug?
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=340771
>
What differs between the files on the 2 arches? Any chance there are
timestamps? Oh, yeah:
"Generated at Wed Jan 31 13:22:54 2007 by ..."
you might want to supress that or filter it out; it'll cause the files
to have different checksums.
oh shoot, this sucks. okay ill see what I can do. Thanks for
figuring that out for me.
5:18 p.m.
Christopher Stone wrote:
On 10/19/07, Eric Sandeen <sandeen(a)redhat.com> wrote:
> Christopher Stone wrote:
>> I am getting a multiarch conflict on %doc files in a devel
>> subpackage[1]. Are we supposed to avoid %doc files in devel packages
>> for multiarch purposes, or am I doing something wrong in my spec, or
>> is this a multiarch rpm bug?
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=340771
>>
> What differs between the files on the 2 arches? Any chance there are
> timestamps? Oh, yeah:
>
> "Generated at Wed Jan 31 13:22:54 2007 by ..."
>
> you might want to supress that or filter it out; it'll cause the files
> to have different checksums.
oh shoot, this sucks. okay ill see what I can do. Thanks for
figuring that out for me.
You could probably just add a patch to modify the shipped
docs/api_footer.html file to remove the timestamp?
-Eric
9:58 p.m.
On Fri, 19 Oct 2007 17:18:15 -0500
Eric Sandeen <sandeen(a)redhat.com> wrote:
You could probably just add a patch to modify the shipped
docs/api_footer.html file to remove the timestamp?
Are these docs generated at build time? If so the timestamps will
still differ and conflict.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
10:07 p.m.
On Fri, 2007-10-19 at 22:58 -0400, Jesse Keating wrote:
On Fri, 19 Oct 2007 17:18:15 -0500
Eric Sandeen <sandeen(a)redhat.com> wrote:
> You could probably just add a patch to modify the shipped
> docs/api_footer.html file to remove the timestamp?
Are these docs generated at build time? If so the timestamps will
still differ and conflict.
Does rpm complain about differing timestamps on files, while the
contents is identical?
I thought rpm would only complain if "contents" differs.
Ralf
10:12 p.m.
On Sat, 20 Oct 2007 05:07:23 +0200
Ralf Corsepius <rc040203(a)freenet.de> wrote:
Does rpm complain about differing timestamps on files, while the
contents is identical?
I thought rpm would only complain if "contents" differs.
You might be right there. I honestly don't have evidence in front of
me one way or the other.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
3:31 a.m.
On Sat, 20 Oct 2007 05:07:23 +0200, Ralf Corsepius wrote:
On Fri, 2007-10-19 at 22:58 -0400, Jesse Keating wrote:
> On Fri, 19 Oct 2007 17:18:15 -0500
> Eric Sandeen <sandeen redhat com> wrote:
>
> > You could probably just add a patch to modify the shipped
> > docs/api_footer.html file to remove the timestamp?
>
> Are these docs generated at build time? If so the timestamps will
> still differ and conflict.
Does rpm complain about differing timestamps on files, while the
contents is identical?
Eric refers to timestamps _in_ the files, however.
10:36 p.m.
On Sat, 2007-10-20 at 10:31 +0200, Michael Schwendt wrote:
On Sat, 20 Oct 2007 05:07:23 +0200, Ralf Corsepius wrote:
> On Fri, 2007-10-19 at 22:58 -0400, Jesse Keating wrote:
> > On Fri, 19 Oct 2007 17:18:15 -0500
> > Eric Sandeen <sandeen redhat com> wrote:
> >
> > > You could probably just add a patch to modify the shipped
> > > docs/api_footer.html file to remove the timestamp?
> >
> > Are these docs generated at build time? If so the timestamps will
> > still differ and conflict.
>
> Does rpm complain about differing timestamps on files, while the
> contents is identical?
Eric refers to timestamps _in_ the files, however.
That was clear. He used
doxygen's textual timestamps as example.
I was referring to filesystem timestamps (stat(2)). They will differ on
generated files in a multiarch'ed setup even if "textual timestamps"
have been filtered/removed.
Ralf
11:14 p.m.
Ralf Corsepius wrote:
On Sat, 2007-10-20 at 10:31 +0200, Michael Schwendt wrote:
> On Sat, 20 Oct 2007 05:07:23 +0200, Ralf Corsepius wrote:
>
>> On Fri, 2007-10-19 at 22:58 -0400, Jesse Keating wrote:
>>> On Fri, 19 Oct 2007 17:18:15 -0500
>>> Eric Sandeen <sandeen redhat com> wrote:
>>>
>>>> You could probably just add a patch to modify the shipped
>>>> docs/api_footer.html file to remove the timestamp?
>>> Are these docs generated at build time? If so the timestamps will
>>> still differ and conflict.
>> Does rpm complain about differing timestamps on files, while the
>> contents is identical?
> Eric refers to timestamps _in_ the files, however.
That was clear. He used doxygen's textual timestamps as example.
I was referring to filesystem timestamps (stat(2)). They will differ on
generated files in a multiarch'ed setup even if "textual timestamps"
have been filtered/removed.
Anyway, I think the answer is: RPM won't complain at install time, near
as I can tell, but if you do rpm -V later you'll see "T" (mtime
mismatch) flags.
...and from elsewhere in the thread, unless you install carefully
(install -p) it's not just generated files that'll mismatch but even
header files that were copied into a devel rpm.
-Eric
11:55 p.m.
On Sat, 2007-10-20 at 23:14 -0500, Eric Sandeen wrote:
Ralf Corsepius wrote:
...and from elsewhere in the thread, unless you install carefully
(install -p) it's not just generated files that'll mismatch but even
header files that were copied into a devel rpm.
Well, my view is converse:
"install -p" doesn't solve anything, because
it doesn't work on generated files.
Ralf
3:50 a.m.
On Sun, Oct 21, 2007 at 06:55:25AM +0200, Ralf Corsepius wrote:
On Sat, 2007-10-20 at 23:14 -0500, Eric Sandeen wrote:
> Ralf Corsepius wrote:
> ...and from elsewhere in the thread, unless you install carefully
> (install -p) it's not just generated files that'll mismatch but even
> header files that were copied into a devel rpm.
Well, my view is converse: "install -p" doesn't solve anything, because
it doesn't work on generated files.
At least it allows to have timestamps kept for unmodified files. But
indeed some touch -r is needed for generated files timestamps.
http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks
--
Pat
4:08 a.m.
On Sun, 2007-10-21 at 10:50 +0200, Patrice Dumas wrote:
On Sun, Oct 21, 2007 at 06:55:25AM +0200, Ralf Corsepius wrote:
> On Sat, 2007-10-20 at 23:14 -0500, Eric Sandeen wrote:
> > Ralf Corsepius wrote:
>
> > ...and from elsewhere in the thread, unless you install carefully
> > (install -p) it's not just generated files that'll mismatch but even
> > header files that were copied into a devel rpm.
> Well, my view is converse: "install -p" doesn't solve anything,
because
> it doesn't work on generated files.
At least it allows to have timestamps kept for unmodified files.
And which problem
does this solve?
IMO, the answer is: Nothing.
Ralf
4:33 a.m.
On Sun, 21 Oct 2007 06:55:25 +0200, Ralf Corsepius wrote:
On Sat, 2007-10-20 at 23:14 -0500, Eric Sandeen wrote:
> Ralf Corsepius wrote:
> ...and from elsewhere in the thread, unless you install carefully
> (install -p) it's not just generated files that'll mismatch but even
> header files that were copied into a devel rpm.
Well, my view is converse: "install -p" doesn't solve anything, because
it doesn't work on generated files.
Right. Originally, the reason why "install -p" and "cp -p" have made
it into pkg review comments is only that _old_ files from tarballs (or
additional SourceX tags) stay _old_ when copying them into the rpm
buildroot -- i.e. their old timestamps are preserved. That way the pkg
users can see the age of files more easily and see when a file has
been updated last. There is a relevant use-case for %doc and %config
at least. It helps a lot upon deciding which files to revisit, e.g.
after a quarterly update, since a fresh timestamp of a %doc file won't
pretend that a pdf/ps manual is a revision from last month when in
fact it has been created in 2001 once and never updated since.
7:02 a.m.
On Sun, 2007-10-21 at 11:33 +0200, Michael Schwendt wrote:
On Sun, 21 Oct 2007 06:55:25 +0200, Ralf Corsepius wrote:
> On Sat, 2007-10-20 at 23:14 -0500, Eric Sandeen wrote:
> > Ralf Corsepius wrote:
>
> > ...and from elsewhere in the thread, unless you install carefully
> > (install -p) it's not just generated files that'll mismatch but even
> > header files that were copied into a devel rpm.
> Well, my view is converse: "install -p" doesn't solve anything,
because
> it doesn't work on generated files.
Right. Originally, the reason why "install -p" and "cp -p" have made
it into pkg review comments is only that _old_ files from tarballs (or
additional SourceX tags) stay _old_ when copying them into the rpm
buildroot -- i.e. their old timestamps are preserved. That way the pkg
users
^^^^^^^ => It's just convenience to cater certain user habits.
Technically, it's sense-free eye-candy.
can see the age of files more easily and see when a file has
been updated last.
There is a relevant use-case for %doc and %config
at least.
How? %doc are completely irrelevant to an installed system, for %config
it's contents that matters (did the files contents change?), not
timestamps.
There is only one use case, where it really matters: time-based
dependencies. Such cases normally only occur for back ups and for
expanded build-trees.
Ralf
8:18 a.m.
On Sun, 21 Oct 2007 14:02:00 +0200, Ralf Corsepius wrote:
> > > ...and from elsewhere in the thread, unless you
install carefully
> > > (install -p) it's not just generated files that'll mismatch but
even
> > > header files that were copied into a devel rpm.
> > Well, my view is converse: "install -p" doesn't solve anything,
because
> > it doesn't work on generated files.
>
> Right. Originally, the reason why "install -p" and "cp -p" have
made
> it into pkg review comments is only that _old_ files from tarballs (or
> additional SourceX tags) stay _old_ when copying them into the rpm
> buildroot -- i.e. their old timestamps are preserved. That way the pkg
> users
^^^^^^^ => It's just convenience to cater certain user habits.
Technically, it's sense-free eye-candy.
I don't disagree.
Except that I see the value in preserving [old!] timestamps as explained
in the prev.msg.
> can see the age of files more easily and see when a file has
> been updated last.
> There is a relevant use-case for %doc and %config
> at least.
How? %doc are completely irrelevant to an installed system,
Why?
for %config
it's contents that matters (did the files contents change?), not
timestamps.
Yes, sure, but for changed contents we have the *.rpmnew/*.rpmsave
mechanism already. For config file templates, default config files or
[init]scripts we don't. Why pretend that a config file (or a file added
via SourceX) is from 2007-10-21 when in fact it has not been changed
for several years? Such a superfluous change in the timestamps also
can result in an unneeded IDS report everytime a pkg is updated.
3:42 a.m.
On Sat, Oct 20, 2007 at 05:07:23AM +0200, Ralf Corsepius wrote:
Does rpm complain about differing timestamps on files, while the
contents is identical?
It doesn't complain but rpm -V shows the differences, it is better if
the stamps are the same for common files coming from different packages.
--
Pat
11:18 a.m.
Patrice Dumas wrote:
On Sat, Oct 20, 2007 at 05:07:23AM +0200, Ralf Corsepius wrote:
> Does rpm complain about differing timestamps on files, while the
> contents is identical?
It doesn't complain but rpm -V shows the differences, it is better if
the stamps are the same for common files coming from different packages.
Waiiit a minute... are you talking about the installed filesystem
timestamps, the mtime that affects the T flag on -V verify? That sounds
like a lot of hoop-jumping to me, although I guess I can see the use for it.
If I look at e2fsprogs-devel for example, and I install x86_64, then
i386, I do get T mtime mismatches. The timestamps on the files are
related to when the rpm was built, presumeably the time at which they
were %installed during the rpm *build*
I suppose that if you made sure that every file install kept the
original timestamp from the upstream tarball, and every generated file
pulled tricks to make sure that the mtime was something (what?) that
matched between all arches you could avoid this... but this sounds like
it needs some infrastructure to make it do-able.
-Eric
12:37 p.m.
Eric Sandeen wrote:
Patrice Dumas wrote:
> On Sat, Oct 20, 2007 at 05:07:23AM +0200, Ralf Corsepius wrote:
>> Does rpm complain about differing timestamps on files, while the
>> contents is identical?
> It doesn't complain but rpm -V shows the differences, it is better if
> the stamps are the same for common files coming from different packages.
Waiiit a minute... are you talking about the installed filesystem
timestamps, the mtime that affects the T flag on -V verify? That sounds
like a lot of hoop-jumping to me, although I guess I can see the use for it.
If I look at e2fsprogs-devel for example, and I install x86_64, then
i386, I do get T mtime mismatches. The timestamps on the files are
related to when the rpm was built, presumeably the time at which they
were %installed during the rpm *build*
I suppose that if you made sure that every file install kept the
original timestamp from the upstream tarball, and every generated file
pulled tricks to make sure that the mtime was something (what?) that
matched between all arches you could avoid this... but this sounds like
it needs some infrastructure to make it do-able.
Urgh... install -p, touch -r ... sorry. I'll shut up now.
-Eric
1:05 p.m.
On Sat, Oct 20, 2007 at 12:37:55PM -0500, Eric Sandeen wrote:
Eric Sandeen wrote:
Urgh... install -p, touch -r ... sorry. I'll shut up now.
To be honest, even though the commands exist, I guess that for complex
packages having to have stamps on all arches the same, even for
generated files seems a bit of a burden to me. In my opinion it should
be optional.
--
Pat
8:34 a.m.
On Sa Oktober 20 2007, Patrice Dumas wrote:
On Sat, Oct 20, 2007 at 05:07:23AM +0200, Ralf Corsepius wrote:
> Does rpm complain about differing timestamps on files, while the
> contents is identical?
It doesn't complain but rpm -V shows the differences, it is better if
the stamps are the same for common files coming from different packages.
Would it be enough to use
%verify(not mtime) /path/to/files
in %files?
Maximum rpm does not really say what this does, except that rpm will not
verify the mtime then.
http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html
Regards,
Till
3:59 p.m.
On Tue, Oct 30, 2007 at 02:34:06PM +0100, Till Maas wrote:
On Sa Oktober 20 2007, Patrice Dumas wrote:
> On Sat, Oct 20, 2007 at 05:07:23AM +0200, Ralf Corsepius wrote:
> > Does rpm complain about differing timestamps on files, while the
> > contents is identical?
>
> It doesn't complain but rpm -V shows the differences, it is better if
> the stamps are the same for common files coming from different packages.
Would it be enough to use
%verify(not mtime) /path/to/files
in %files?
I guess so. For some files it could even make more sense than some
things I propose in the multilib trickes page. But when the timestamp
changes comes from patching or not using -p when copying it makes sense
to set them right.
--
Pat
4:55 a.m.
Eric Sandeen <sandeen(a)redhat.com> writes:
You could probably just add a patch to modify the shipped
docs/api_footer.html file to remove the timestamp?
will not work e.g. for PDF or PS doc. Ditto for HTML doxygen doc where
anchors are named with unique random identifiers.
Enrico
11:22 a.m.
Enrico Scholz wrote:
Eric Sandeen <sandeen(a)redhat.com> writes:
> You could probably just add a patch to modify the shipped
> docs/api_footer.html file to remove the timestamp?
will not work e.g. for PDF or PS doc. Ditto for HTML doxygen doc where
anchors are named with unique random identifiers.
Yeesh. For things that contain simple generation timestamps, we could
probably make some filters to take those out. e2fsprogs has something
like that:
[root@localhost e2fsprogs-1.40.2]# cat ./po/remove-potcdate.sin
# Sed script that remove the POT-Creation-Date line in the header entry
# from a POT file.
....
but for anything which contains uuids generated at build time... good
luck I guess! :)
-Eric
11:51 a.m.
Eric Sandeen wrote:
Enrico Scholz wrote:
> Eric Sandeen <sandeen(a)redhat.com> writes:
>
>> You could probably just add a patch to modify the shipped
>> docs/api_footer.html file to remove the timestamp?
> will not work e.g. for PDF or PS doc. Ditto for HTML doxygen doc where
> anchors are named with unique random identifiers.
Yeesh. For things that contain simple generation timestamps, we could
probably make some filters to take those out. e2fsprogs has something
like that:
[root@localhost e2fsprogs-1.40.2]# cat ./po/remove-potcdate.sin
# Sed script that remove the POT-Creation-Date line in the header entry
# from a POT file.
....
but for anything which contains uuids generated at build time... good
luck I guess! :)
And I'm afraid this does apply to you, Christopher, I should have looked
more closely. If for example you diff classcal3d_1_1RefCounted.html
between x86_64 and x86, you'll see this.
(pseudodiff):
-<a class="anchor"
name="fe153da64cbdd43c0ab660327001a25e"></a>
+<a class="anchor"
name="23e13384bbde2cbd2f302e6ad70eae2b"></a>
-Eric
12:01 p.m.
Eric Sandeen wrote:
And I'm afraid this does apply to you, Christopher, I should
have
looked more closely. If for example you diff
classcal3d_1_1RefCounted.html between x86_64 and x86, you'll see
this.
(pseudodiff):
-<a class="anchor"
name="fe153da64cbdd43c0ab660327001a25e"></a>
+<a class="anchor"
name="23e13384bbde2cbd2f302e6ad70eae2b"></a>
Could docs like this be split out into noarch subpackages? Or perhaps
pre-generated and then installed from a Source1: line so that they'd
match across arches?
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The marvel of all history is the patience with which men and women
submit to burdens unnecessarily laid upon them by their governments.
-- William H. Borah
11:01 a.m.
On 10/20/07, Todd Zullinger <tmz(a)pobox.com> wrote:
Eric Sandeen wrote:
> And I'm afraid this does apply to you, Christopher, I should have
> looked more closely. If for example you diff
> classcal3d_1_1RefCounted.html between x86_64 and x86, you'll see
> this.
>
> (pseudodiff):
>
> -<a class="anchor"
name="fe153da64cbdd43c0ab660327001a25e"></a>
> +<a class="anchor"
name="23e13384bbde2cbd2f302e6ad70eae2b"></a>
Could docs like this be split out into noarch subpackages? Or perhaps
pre-generated and then installed from a Source1: line so that they'd
match across arches?
Wow, please don't ask me to do this, the bug is clearly yum or doxygen.
12:40 p.m.
Christopher Stone wrote:
> Could docs like this be split out into noarch subpackages? Or
> perhaps pre-generated and then installed from a Source1: line so
> that they'd match across arches?
Wow, please don't ask me to do this, the bug is clearly yum or
doxygen.
Perhaps, but sometimes it's necessary to work around problems in the
underlying tools in order to provide a better end user experience. If
there is an easy to fix bug in yum or doxygen, then someone will fix
it soon enough. Until/unless that happens, what would be wrong with
pre-generating the docs and including them that way? See the id3lib
package for an example. Hans just did this there to fix multilib
problems.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The average woman would rather be beautiful than smart because the
average man can see better than he can think.
12:46 p.m.
On Sun, Oct 21, 2007 at 01:40:44PM -0400, Todd Zullinger wrote:
Perhaps, but sometimes it's necessary to work around problems in the
underlying tools in order to provide a better end user experience. If
there is an easy to fix bug in yum or doxygen, then someone will fix
it soon enough. Until/unless that happens, what would be wrong with
pre-generating the docs and including them that way? See the id3lib
package for an example. Hans just did this there to fix multilib
problems.
It is good that Hans fixed it, but I don't think that it should be
mandatory, if yum or doxygen is broken (in my opinion doxygen should
produce reproducable documents).
--
Pat
9:19 p.m.
On Sun, 2007-10-21 at 09:01 -0700, Christopher Stone wrote:
On 10/20/07, Todd Zullinger <tmz(a)pobox.com> wrote:
> Eric Sandeen wrote:
> > And I'm afraid this does apply to you, Christopher, I should have
> > looked more closely. If for example you diff
> > classcal3d_1_1RefCounted.html between x86_64 and x86, you'll see
> > this.
> >
> > (pseudodiff):
> >
> > -<a class="anchor"
name="fe153da64cbdd43c0ab660327001a25e"></a>
> > +<a class="anchor"
name="23e13384bbde2cbd2f302e6ad70eae2b"></a>
>
> Could docs like this be split out into noarch subpackages? Or perhaps
> pre-generated and then installed from a Source1: line so that they'd
> match across arches?
Wow, please don't ask me to do this, the bug is clearly yum or doxygen.
rpmlib is complaining about the files not matching. Not yum. And I
actually don't think this is a bug in rpm, either.
-sv
10:04 p.m.
On 10/21/07, seth vidal <skvidal(a)fedoraproject.org> wrote:
On Sun, 2007-10-21 at 09:01 -0700, Christopher Stone wrote:
> On 10/20/07, Todd Zullinger <tmz(a)pobox.com> wrote:
> > Eric Sandeen wrote:
> > > And I'm afraid this does apply to you, Christopher, I should have
> > > looked more closely. If for example you diff
> > > classcal3d_1_1RefCounted.html between x86_64 and x86, you'll see
> > > this.
> > >
> > > (pseudodiff):
> > >
> > > -<a class="anchor"
name="fe153da64cbdd43c0ab660327001a25e"></a>
> > > +<a class="anchor"
name="23e13384bbde2cbd2f302e6ad70eae2b"></a>
> >
> > Could docs like this be split out into noarch subpackages? Or perhaps
> > pre-generated and then installed from a Source1: line so that they'd
> > match across arches?
>
> Wow, please don't ask me to do this, the bug is clearly yum or doxygen.
rpmlib is complaining about the files not matching. Not yum. And I
actually don't think this is a bug in rpm, either.
Except for the fact that you can install both arches just fine using
rpm, but it fails with yum.
10:04 p.m.
On Sun, 2007-10-21 at 20:04 -0700, Christopher Stone wrote:
On 10/21/07, seth vidal <skvidal(a)fedoraproject.org> wrote:
>
> On Sun, 2007-10-21 at 09:01 -0700, Christopher Stone wrote:
> > On 10/20/07, Todd Zullinger <tmz(a)pobox.com> wrote:
> > > Eric Sandeen wrote:
> > > > And I'm afraid this does apply to you, Christopher, I should
have
> > > > looked more closely. If for example you diff
> > > > classcal3d_1_1RefCounted.html between x86_64 and x86, you'll see
> > > > this.
> > > >
> > > > (pseudodiff):
> > > >
> > > > -<a class="anchor"
name="fe153da64cbdd43c0ab660327001a25e"></a>
> > > > +<a class="anchor"
name="23e13384bbde2cbd2f302e6ad70eae2b"></a>
> > >
> > > Could docs like this be split out into noarch subpackages? Or perhaps
> > > pre-generated and then installed from a Source1: line so that they'd
> > > match across arches?
> >
> > Wow, please don't ask me to do this, the bug is clearly yum or doxygen.
>
> rpmlib is complaining about the files not matching. Not yum. And I
> actually don't think this is a bug in rpm, either.
Except for the fact that you can install both arches just fine using
rpm, but it fails with yum.
really? That's interesting. It should be consistent b/c at the point
where the error is coming from in yum, all of the operation is inisde
rpmlib.
-sv
10:10 p.m.
On 10/21/07, seth vidal <skvidal(a)fedoraproject.org> wrote:
On Sun, 2007-10-21 at 20:04 -0700, Christopher Stone wrote:
> On 10/21/07, seth vidal <skvidal(a)fedoraproject.org> wrote:
> >
> > On Sun, 2007-10-21 at 09:01 -0700, Christopher Stone wrote:
> > > On 10/20/07, Todd Zullinger <tmz(a)pobox.com> wrote:
> > > > Eric Sandeen wrote:
> > > > > And I'm afraid this does apply to you, Christopher, I should
have
> > > > > looked more closely. If for example you diff
> > > > > classcal3d_1_1RefCounted.html between x86_64 and x86, you'll
see
> > > > > this.
> > > > >
> > > > > (pseudodiff):
> > > > >
> > > > > -<a class="anchor"
name="fe153da64cbdd43c0ab660327001a25e"></a>
> > > > > +<a class="anchor"
name="23e13384bbde2cbd2f302e6ad70eae2b"></a>
> > > >
> > > > Could docs like this be split out into noarch subpackages? Or
perhaps
> > > > pre-generated and then installed from a Source1: line so that
they'd
> > > > match across arches?
> > >
> > > Wow, please don't ask me to do this, the bug is clearly yum or
doxygen.
> >
> > rpmlib is complaining about the files not matching. Not yum. And I
> > actually don't think this is a bug in rpm, either.
>
> Except for the fact that you can install both arches just fine using
> rpm, but it fails with yum.
really? That's interesting. It should be consistent b/c at the point
where the error is coming from in yum, all of the operation is inisde
rpmlib.
yep,
rpm -ivh cal3d-devel-0.11.0-5.fc8.x86_64.rpm cal3d-devel-0.11.0-5.fc8.i386.rpm
works like a charm.
not so well using yum localinstall...
10:11 p.m.
On Sun, 21 Oct 2007 20:10:41 -0700
"Christopher Stone" <chris.stone(a)gmail.com> wrote:
yep,
rpm -ivh cal3d-devel-0.11.0-5.fc8.x86_64.rpm
cal3d-devel-0.11.0-5.fc8.i386.rpm
works like a charm.
not so well using yum localinstall...
Erm, try installing the x86_64 package. Then install the i386 one.
Two transactions, not one.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
10:16 p.m.
On 10/21/07, Jesse Keating <jkeating(a)redhat.com> wrote:
On Sun, 21 Oct 2007 20:10:41 -0700
"Christopher Stone" <chris.stone(a)gmail.com> wrote:
> yep,
>
> rpm -ivh cal3d-devel-0.11.0-5.fc8.x86_64.rpm
> cal3d-devel-0.11.0-5.fc8.i386.rpm
>
> works like a charm.
>
> not so well using yum localinstall...
Erm, try installing the x86_64 package. Then install the i386 one.
Two transactions, not one.
Thank god there are no plans to remove rpm from Fedora... ;-)
1:54 a.m.
New subject: Multiarch conflicts on packages with resources
Christopher Stone píše v Pá 19. 10. 2007 v 15:02 -0700:
I am getting a multiarch conflict on %doc files in a devel
subpackage[1]. Are we supposed to avoid %doc files in devel packages
for multiarch purposes, or am I doing something wrong in my spec, or
is this a multiarch rpm bug?
I have similar problem on a subpackage, which contains additional
plugins + their resources [1]. The main source package (codeblocks) is
divided into 4 binary subpackages
- codeblocks - main executable, default plugins + their resources
- codeblocks-libs - shared libraries for the main executable and plugins
- codeblocks-devel - devel libraries and headers
- codeblocks-contrib - additional plugins + their resources
The resources are packed from source files with zip during building of
the package. The -devel and -libs subpackage are multiarch aware AFAIK
[2], but there is no reason to install both 32 and 64 bit version of the
main subpackage and the -contrib subpackage. Does anybody see a way, how
to fix this, when creating noarch subpackages for an arch package is not
possible?
Thanks
Dan
[1] https://bugzilla.redhat.com/show_bug.cgi?id=340911
[2] https://bugzilla.redhat.com/show_bug.cgi?id=228356
6:58 a.m.
New subject: Multiarch conflicts on packages with resources
On Sun, 21 Oct 2007 08:54:53 +0200
"Dan Horák" <dan(a)danny.cz> wrote:
The resources are packed from source files with zip during building
of
the package. The -devel and -libs subpackage are multiarch aware AFAIK
[2], but there is no reason to install both 32 and 64 bit version of
the main subpackage and the -contrib subpackage. Does anybody see a
way, how to fix this, when creating noarch subpackages for an arch
package is not possible?
It would be best to discover why both arches of codeblocks are being
tagged as multilib. Is there still some library left that is in the
codeblocks package?
--
Jesse Keating
Fedora -- All my bits are free, are yours?
7:04 a.m.
New subject: Multiarch conflicts on packages with resources
On Sun, 2007-10-21 at 07:58 -0400, Jesse Keating wrote:
On Sun, 21 Oct 2007 08:54:53 +0200
"Dan Horák" <dan(a)danny.cz> wrote:
> The resources are packed from source files with zip during building of
> the package. The -devel and -libs subpackage are multiarch aware AFAIK
> [2], but there is no reason to install both 32 and 64 bit version of
> the main subpackage and the -contrib subpackage. Does anybody see a
> way, how to fix this, when creating noarch subpackages for an arch
> package is not possible?
It would be best to discover why both arches of codeblocks are being
tagged as multilib. Is there still some library left that is in the
codeblocks package?
The codeblocks issue seems to be timestamps on otherwise
identical files
inside of *.zip's archives. I would assume touch and timestamp magic
during building these packages would be able to fix this issue.
Ralf
7:05 a.m.
New subject: Multiarch conflicts on packages with resources
On Sun, 21 Oct 2007 07:58:38 -0400
Jesse Keating <jkeating(a)redhat.com> wrote:
> The resources are packed from source files with zip during
building
> of the package. The -devel and -libs subpackage are multiarch aware
> AFAIK [2], but there is no reason to install both 32 and 64 bit
> version of the main subpackage and the -contrib subpackage. Does
> anybody see a way, how to fix this, when creating noarch
> subpackages for an arch package is not possible?
It would be best to discover why both arches of codeblocks are being
tagged as multilib. Is there still some library left that is in the
codeblocks package?
Bingo. The main subpackage isn't multilib. However the
codeblocks-contrib package /is/ because it installs a library in the
standard library path:
/usr/lib64/libwxsmithlib.so.0
/usr/lib64/libwxsmithlib.so.0.0.1
--
Jesse Keating
Fedora -- All my bits are free, are yours?
7:30 a.m.
New subject: Multiarch conflicts on packages with resources
Jesse Keating píše v Ne 21. 10. 2007 v 08:05 -0400:
On Sun, 21 Oct 2007 07:58:38 -0400
Jesse Keating <jkeating(a)redhat.com> wrote:
> > The resources are packed from source files with zip during building
> > of the package. The -devel and -libs subpackage are multiarch aware
> > AFAIK [2], but there is no reason to install both 32 and 64 bit
> > version of the main subpackage and the -contrib subpackage. Does
> > anybody see a way, how to fix this, when creating noarch
> > subpackages for an arch package is not possible?
>
> It would be best to discover why both arches of codeblocks are being
> tagged as multilib. Is there still some library left that is in the
> codeblocks package?
Bingo. The main subpackage isn't multilib. However the
codeblocks-contrib package /is/ because it installs a library in the
standard library path:
/usr/lib64/libwxsmithlib.so.0
/usr/lib64/libwxsmithlib.so.0.0.1
Then I will create a new subpackage -contrib-libs, thanks Jesse.
Dan
6029
days inactive
6040
days old
39 comments
11 participants
participants (11)
-
Christopher Stone -
Dan Horák -
Enrico Scholz -
Eric Sandeen -
Jesse Keating -
Michael Schwendt -
Patrice Dumas -
Ralf Corsepius -
Seth Vidal -
Till Maas -
Todd Zullinger