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 |