On 2 Jun 2012, at 03:56, Erich Dollansky wrote: > But I have to mention one disadvantage. The ports are in no way linked to the > releases. This leads to situations in which a small change in a basic library > will result in a complete update of the installed ports. I expressed this > already many time here. It would be of advantage if the ports tree would also > have tags like the base system itself.
OpenBSD did this for a while, but they gave up because they weren't doing it well enough to recommend it and it did more harm to users to do it badly than not at all. Ideally, you want to get security fixes for all installed applications, but nothing else, in this model. There are two ways of doing this: - Back-port security fixes to the version shipped with the base system - Import the security-fixed version into the stable set. The second option has the problem that you identified: if the new version depends on a newer library, then this cascades and you end up needing to import a new version of hundreds of ports. The first option has a much simpler disadvantage: it requires a huge amount of manpower. Companies like Red Hat can do this because they charge their users a lot for this service. We could probably do this if we had enough users willing to pay for the service, or if we restrict it to a set of packages that do their own security backports upstream. The problem with the second option can be alleviated if we make it easier to have multiple versions of libraries installed at the same time (this is something that the PBI system in PC-BSD does, albeit in an ugly hackish way that could be improved significantly with a bit of assistance from rtld). David_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
