On 06/04/12 17:24, Chris Rees wrote: > On 3 June 2012 21:55, O. Hartmann <ohartman_at_zedat.fu-berlin.de> wrote: >> On 06/03/12 15:29, Erich wrote: >>> Hi, >>> >>> On 03 June 2012 PM 5:14:10 Adam Strohl wrote: >>>> On 6/3/2012 11:14, Erich wrote: >>>>> What I really do not understand in this whole discussion is very simple. Is it just a few people who run into problems like this or is this simply ignored by the people who set the strategy for FreeBSD? >>>>> >>>>> I mention since yeares here that putting version numbers onto the port tree would solve many of these problems. All I get as an answer is that it is not possible. >>>>> >>>>> I think that this should be easily possible with the limitation that older versions do not have security fixes. Yes, but of what help is a security fix if there is no running port for the fix? >>>> >>>> I feel like I'm missing something. Why would you ever want to go back >>>> to an old version of the ports tree? You're ignoring tons of security >>>> issues! >> >> ... I think the PNG update isn't a security issue. And for not being a >> security issue, it triggered an inadequate mess! >> >>>> >>>> And if a port build is broken then the maintainer needs to fix it, that >>>> is the solution. >> >> Look at the comment of the maintainer of LibreOffice ... >>>> >>>> I must be missing something else here, it just seems like the underlying >>>> "need" for this is misguided (and dangerous from a security perspective). >>> >>> yes, you miss a very simple thing. Updated this morning your ports tree. Your client asks for something for Monday morning for which you need now a program which needs some kind of PNG but you did not install it. >> >> ... I spent now two complete days watching my boxes updating their >> ports. Several ports do not compile anymore (inkscape, libreoffice, >> libxul, to name some of the very hurting ones!). >> >>> >>> Do you have a machine that is fast enough to upgrade all your ports and still finish what your client needs Monday morning? >> >> Even my fastest box, a brand new 6 core Sandy-Bridge-E, wasn't capable >> of compiling all the ports in due time. Several ports requested >> attendance, several, as mentioned, didn't compile out of the blue. >> >>> >>> The ports tree is not broken as such. Only the installation gets broken in some sense. Have a version number there would allow people to go back to the last known working ports tree, install the software - or whatever has to be done - with a working system. >>> >>> Of course, the next step will be an upgrade. But only after the work which brings in the money is done. >>> >>> You do not face this problem on Windows. You can run a 10 year old 'kernel' and still install modern software. >>> >>> Erich >> >> I like having a very modern system with the most recent software. But in >> some cases, like these days with the PNG, FreeBSD's ports becomes again >> a problem. There is no convenient way to downgrade or allow the >> user/admin managing how to deal with the load of updates. > > You can't have both. As has been repeatedly explained to you, you > should not expect an easy life with the very latest of software. Well, and repeatedly (no offense!) I will point out in this case, that I was FORCED having the latest software by the ports system! That it a difference in having running FreeBSD CURRENT on my own risk, or FreeBSD-STABLE due to new hardware and new drivers only supported by those and having a regular port update, which blows up the system because of the newest software! I take the burden of having not an easy life, but this, what is expected from so many "users" of FreeBSD, is simply beyond ... > > Either stick to releases, or put up with lots of compiling etc-- you > should not complain because of self-inflicted problems. As I repeatedly have to point out in this case - the issue is not with STABLE and CURRENT, it is also with RELEASE. And as it has been pointed out herein so many times: FreeBSD ports lack in a version tagging. How would you suggest avoiding the problems we face with the ports by being sticky on RELEASE, if the problem is spread over all branches? > > Please remember that we do compile packages for release, or if more up > to date packages are required you can use the stable package sets > which are rarely over five days or so. If it is about the binary packages - then you're right. Stick with RELEASE and binary packages - if available (the mentioned office packages are often much delayed). In such a case one is better with a binary spread version of an OS and this would exactly hit the subject of the thread: Why NOT using ... blablabla > > Chris At the end, I'd like to see more care about the way ports get updated. There is no way to avoid messes like described at this very moment. And it is a kind of unedifying . oh
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:27 UTC