On 10/30/07, Vincenzo Ciancia <[EMAIL PROTECTED]> wrote: > Christofer C. Bell ha scritto: > > > There's nothing wrong going on here. This was a simple case of user > > error. The user installed software (albeit under a different release) > > that was not compatible with the current release. The system was > > configured to use software installed in /usr/local prior to being > > upgraded, and continued to do so after being upgraded. That this > > software was incompatible with the newly installed operating system is > > not the fault of the operating system. > > Not to be picky, but the libz that I had in my system actuall was > compatible with the release I was using, hence I did never notice a > problem. Is the _new_ release which is not compatible, where is my error > then? If I can't know in advance what libraries will break the new > system, I have to remove the whole /usr/local before upgrading, this can > be done harmlessly by the system upgrader.
I understand that. I'm not saying you're "at fault" in terms of you being negligent, not in the least. I'm saying that the "issue" here isn't caused by the the distribution. If you want to blame some abstract document, blame the FSSTD for allowing Unix systems to even have a /usr/local. Ubuntu is obeying that standard here. It's not messing with anything in /usr/local. That the software installed there was not compatible with Gutsy is not the fault of Ubuntu. Basically what this boils down to is that yes, the onus is on the system operator (user, administrator) to determine, either in advance or through testing, that software installed by hand is or is not compatible with a new release of the operating system. If you can fault Ubuntu with anything here, it's that compliance with the FSSTD forces Ubuntu to assume that software in /usr/local is compatible with itself. Because software in this location is, by definition, installed by hand, compatibility testing will likewise have to be "by hand." > If the user has to foresee any problem with non-distribution packages or > programs, why does ubuntu modify /etc/apt/sources.list? Shouldn't it > apply the same principle, and just leave it untouched? If third party > repositories break the system upgrade, it's just an user error. Yes, if third party repositories break the system, it is user error. I would in this case suggest using the /etc/apt/sources.list.d directory for including third party archives. It is a known caveat that including third party repositories with your sources can cause issues with your operating system. This is not the fault of Ubuntu and the system should not be expected to protect you from yourself in this case. -- Chris "To announce that there must be no criticism of the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public," said President Theodore Roosevelt. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
