Hi, On 02 June 2012 AM 11:39:16 David Chisnall wrote: > 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: > I would even accept to get the 'release' ports tree without security fixes just to have a system which is up and running fast after I tried an upgrade like what is happening at the moment with PNG dependent ports.
As situations like this are rarely needed, I would not push for a fully secured system. Do not see it too complicated what I want. It is really just a system I can fall back at the spot if things got complicated with with a csup the new ports tree just to get something installed. A user who really wants to run a totally outdated system should know what he/she is doing and not complain when things go wrong. > - 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). > This would be ideal anyway and also most likely avoid the cause for going back. Just keep both versions in the system and let the system decide which one to use. Erich _______________________________________________ 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"
