| 1 |
Hello, |
| 2 |
we are dropping behind in libpng versions quite badly, but I fear the |
| 3 |
move to the new version will be a difficult one. |
| 4 |
|
| 5 |
When emerging libpng-1.2.1 it will break almost all programs that link |
| 6 |
to libpng.so.2, (new version is libpng.so.3) |
| 7 |
|
| 8 |
This is solved by a simple rebuild of the affected packages, but that's |
| 9 |
not something that feels nice in many cases. |
| 10 |
|
| 11 |
as more and more packages depend on the newer 1.2.1 version (that has |
| 12 |
quite some changes to 1.0.12, including optimizations) |
| 13 |
|
| 14 |
Now, I'm looking for a way to smoothly show this into portage without |
| 15 |
breaking too much of the users applications. |
| 16 |
|
| 17 |
I've figured two approaches to this: |
| 18 |
A) update the ~200 ebuilds that link to libpng to point at |
| 19 |
media-libs/libpng-1.2.1 and mask them, only to unmask it all at one |
| 20 |
point. |
| 21 |
|
| 22 |
B) force rebuild of certain installed packages. |
| 23 |
|
| 24 |
|
| 25 |
for b I see quite some solutions that are "nice" to use, a magic |
| 26 |
"rebuild ( )" flag for the installed packages, or an update-script that |
| 27 |
is executed or that the user is told to execute when they have installed |
| 28 |
the new version of libpng. |
| 29 |
|
| 30 |
a question that arise is "can we in the pkg_postinst() process force |
| 31 |
emerge of some pieces of software?" or do we include an automagic |
| 32 |
updater script? |
| 33 |
|
| 34 |
or do we do it the "hard" way? |
| 35 |
|
| 36 |
//Spider |
| 37 |
-- |
| 38 |
begin happy99.exe |
| 39 |
This is a .signature virus! Please copy me into your .signature! |
| 40 |
See Microsoft KB Article Q265230 for more information. |
| 41 |
end |
Archives