[argyllcms] Re: Argyllcms 1.0.1 packaged in fedora-devel

On Sunday 27 July 2008 01:26:47 pm Ben Goren wrote:
> On 2008 Jul 27, at 1:06 PM, Nicolas Mailhot wrote:
>  > On Sun, 2008-07-27 at 21:46 +0200, edmund ronald wrote:
>  >> I'm sorry,  there is  something here  I don't  understand: If I
>  >> ***REQUIRE*** unchanging semantics as far as possible, bugs and
>  >> all, can I enforce that without static linking ?
>  >
>  > I'm sorry, but  unchanging does not exist (and  I've worked with
>  > people who stockpiled components in nitrogen for decades).
>  >
>  > You either  learn to manage changes  or hit a big  painful brick
>  > wall sooner or later.
>
> If I'm not  mistraken, edmund (and the others)  is (are) concerned
> with unknown and unexpected changes outside of his (their) control
> and  ability to  test  for. And, since  shared libraries  *aren't*
> always backwards  compatible, never  mind that the  version number
> says that  it should be,  he needs a  way to specify,  say, ``Only
> version 3.1.4 of libFoo, nothing newer or older.''  After all, the
> bug fixed  in 3.1.5 may  well break the workaround  edmund already
> coded.
>
> Of course,  the next version  of edmund's code will,  if possible,
> use 3.1.5 instead  of the b0rked 3.1.4. But changing  the code out
> from underneath him...well, that's the  sort of problem you create
> by  trying  to solve  the  limitations  of the  previous  decade's
> computers.
>
> Cheers,

Some distros solve this problem as part of the packaging system.  For example 
I use Gentoo and it's ebuilds (packages on Gentoo) have the ability to specify 
versions for any other software that the package may need.  

Most of the time we see things like myApp needs libFoo-3.0 or newer (=> 
libFoo-3.0) but it is possible to specify a specific version like = 
libFoo-3.1.4 or a range such as => libFoo3.1.2 & =< libFoo-3.1.4.  So this is 
capable of being very fine grained.

If some app needs version 3.1.4 of libFoo and the user tries to install libFoo 
3.1.5 (or 3.1.4-r1 or 3.1.3 for that matter) or something that requires a 
different version of libFoo it will issue an error message and basically say 
that myApp-1.0 is blocking libFoo-3.1.5.  A user seeing this could do several 
things to resolve the issue.  But assuming that the user considers myApp 
important he will mask all versions of libFoo other than 3.1.4 and not install 
other software that requires a libFoo other than 3.1.4.  I have had this sort 
of thing happen a few times in the last two years or so I have used Gentoo and 
it works well and at most only causes minor issues for users.

Gentoo also has the ability to slot packages so that more than one version of 
a package can exist at a given time on a system.  This include libraries.  In 
some cases these sloted packages must be manually switched by a user (gcc, 
current kernel source are like this) when needed but in other cases there is 
automatic switching.  For example, I currently have KDE 3.5.9, 4.0.4 and 4.1-
rc1 installed on my machine and I can switch between these with out any 
difficulty but it is not possible to run more than one KDE slot at any given 
time for a given user ID.

So clearly these types of controls are possible and exist at least in some 
distros because there are cases where this is needed.  Edmund, depending on 
the distro this issue is already solved if the app in question is properly 
packaged.  By the way this is definitely a valid concern.  I am not sure how 
common this is with other distros but I suspect that most of them have this 
kind of functionality.

As a side note until Windows 2000 the Windows system libraries were subject to 
arbitrary replacement by other non-system apps and in fact it was common for  
fooApp to overwrite system libraries when it was being installed.   At that 
time I worked in IT for a large corporation and the situation as it existed 
prior to Windows 2000 was a major support issue for us (we were using NT) and 
at one point someone (who must be a lot smarter than me) calulated that this 
specific issue was costing that company about $10 million a year in added 
support costs. Starting with Windows 2000 Microsoft put in place a protection 
scheme for these files.  What it does is allows fooApp to replace the system 
libraries during install but as part of this process it keeps a copy of the 
correct system library and then replaces it once the install for fooApp is 
done.  This is basically the same issue on Windows only on Windows the fix 
only takes care of system specific libraries so is more limited than what we 
see with many Linux distros.  In addition this does not prevent Windows update 
from clobering a specific version of a system library that your app may need.  
Just thought that I would point out that this problem is not limited to *nix 
systems.

Hal

Other related posts: