Re: Soname bump libpng (rawhide) - new libraries libpng.16.so and libpng16.so.16.2.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/22/2013 09:51 AM, Petr Hracek wrote:
Thank you for really deep explanation.
We had discussion how to do that issue
and we will created a side tag for that.

Compatibility package will not be needed and BZ will be closed.

Best regards / S pozdravem
Petr Hracek

On 05/21/2013 03:43 PM, Kalev Lember wrote:
2013-05-20 09:03, Petr Hracek skrev:
Just a one short question.

You are talking about side tag.
Could you please describe me what are you talking about?
It seems like I am a newbie.
Koji organizes builds by labelling them with tags. There's a a tag for
f19, a tag for f19-updates, a tag for f20, and a number of others. These
decide what repository packages from a particular build end up in.

For rawhide, all packages that are built get automatically tagged with
the f20 tag, and this is what causes newly built packages to appear in
the rawhide build roots and in daily rawhide composes.

Earlier you "untagged" your libpng 1.6 build and that was enough to
remove it from the repos.

What Adam means is that it's possible to ask the koji admins to create a
new side tag + a separate build target in koji, so that the libpng 1.6
rebuilds could happen without disturbing the regular rawhide repos.

Such side build targets can be used to handle soname bumps: A library
package with a soname bump is tagged with the side tag and appears in
the side target, then all consumers are rebuilt against the new library
using the side build target, and finally once all is done, the new
builds are tagged back into the main rawhide all together.

In this case however I think it's not necessary to have a side tag. You
are already working on a compatibility libpng15 package [1] and that
removes the need to rebuild everything at once -- with that in place,
builds can happen slowly, over time. The side tag makes sense if you do
_not_ want to provide the compatibility library.

Hope this helps,
Kalev

[1] https://bugzilla.redhat.com/show_bug.cgi?id=964161



Ok, well.
It seems that libpng15 compatibility package is built in rawhide.
What are the next steps?
Tagged already built libpng(1.6) package?

I do not want to break rawhide completely and
I would like to avoid all mistakes which can be done from my side.

If I understand whole process then I can tagged libpng package again
and create a lot of bugzillas for support libpng1.6, right?

I will make a notes what to do that in the future of course.

--
Best regards / S pozdravem
Petr Hracek

--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux