Prev: Stale BINDings
Next: NYC LOCAL: Tuesday 30 March 2010 NYLUG Hackfest
From: Michel Talon on 29 Mar 2010 13:32
Bob Melson <amia9018(a)mypacks.net> wrote:
> That makes no sense. I have a system. The system has ports - needs 'em to
> be useful. The ports need to be updated for various reasons. Users are

No, ports don't need to be updated regularly. There is a basic axiom: if
it ain't break, ain't fix it. If you have a machine on the web, needing
frequent security updates, then the problem s different, but in this
case you do the *minimal* install which does the job, and you read
UPDATING, and follow the mailing lists.
If you want frequent updates without having to take care of anything,
then run Ubuntu, because FreeBSD is not for you.

>
> But that's not the point and never was.

Indeed.

> But to have, e.g., the multiple ports that rely on cairo fail to upgrade
> because cairo can't be upgraded because IT depends on png ... That's a
> failure of the process and is inexcusable -

It is very excusable, FreeBSD has a limited number of people taking care
of ports, and a huge number of ports. The only other system with such
coverage is Debian and it has 1000 "developers". This is what is
supposed to allow seamless updates, and only with the Stable version.
Ubuntu provides a reasonably fine update for a mix of Unstable and
Testing. FreeBSD doesn't have the infrastructure and workforce to do the
same. For a very small set of ports, OpenBSD is said to be fine.

> distant future. I've watched the system grow and improve, but I've also
> seen the ports _system_ deteriorate at the same time.

I have the same experience, but i think that the cause is mainly the
huge growth of the ports system which has become hard to manage, and also
the external catastrophes like the conversion of Xorg to the Gnu build
system, called "modularisation". Nowadays you can hardly run a desktop
without a thousand ports installed, which causes considerable headache
to upgrade.



--

Michel TALON

From: Ted Nolan <tednolan> on 29 Mar 2010 13:49
I've been running FreeBSD since 2.x, and I've *never* upgraded the ports
tree. While I'm running a release, I use the ports that came with that,
when I move to the next release, voila, I have a new set of ports.

Sure, they aren't the bleeding edge versions, but that's rarely been
an issue (and when it has, I can just download and build what I need
from source). I find that FreeBSD just *works*, and I don't need
to be fooling with it all the time.

Ted
--
------
columbiaclosings.com
What's not in Columbia anymore..
From: Warren Block on 29 Mar 2010 16:19
Bob Melson <amia9018(a)mypacks.net> wrote:
....
>>> Secondly, not everybody subscribes to the mailing lists, particularly
>>> when they're not active porters, maintainers, commiters or otherwise
>>> actively involved with development.
>>
>> Updating ports often and not watching the mailing lists are kind of at
>> odds.
>>
>> You could add
>>
>> *default date=2010.03.28.06.00.00
>> # here be dragons
>>
>> to your ports-supfile. But how do you tell when it's safe to remove?
>
> Warren:
>
> That makes no sense.
....
> But that's not the point and never was.

> The point is/was, or so I thought when writing my original post, that
> recent upgrade cycles have been, shall we say, less than encouraging
> and that, instead of getting better, the situation seems to be getting
> worse each cycle, with multiple ports broken because the s/w _they're_
> dependent on is broken or incompletely tested or, well, you pick a
> reason. That should NEVER be and updates should not be announced
> until there's some assurance that Joe User - who may be a home user or
> an admin somewhere or anybody from naive to experienced - can reliably
> do an upgrade by following the instructions in the handbook.

That's why I suggested using a cvs date. When you know the date of the
breakage, you can travel back in time and buy a lottery ticket!

If entries in UPDATING were strictly formatted, an automated tool like
portaudit could do things based on them. But it's not, so forget that.

Sometimes things just suck, and then they get better. Yesterday, a
bunch of ports were broken by png changes, today all of the ones that
were broken (here) now work. In less than 24 hours. As suckage goes,
it wasn't very bad for very long. If you hadn't updated your ports
until today, or maybe tomorrow/next week/fall, maybe you wouldn't have
even noticed.

Of course, there's more big changes coming up...

--
Warren Block * Rapid City, South Dakota * USA
From: Bob Melson on 29 Mar 2010 17:50
On Monday 29 March 2010 14:19, Warren Block (wblock(a)wonkity.com) opined:

> Bob Melson <amia9018(a)mypacks.net> wrote:
> ...
>>>> Secondly, not everybody subscribes to the mailing lists, particularly
>>>> when they're not active porters, maintainers, commiters or otherwise
>>>> actively involved with development.
>>>
>>> Updating ports often and not watching the mailing lists are kind of at
>>> odds.
>>>
>>> You could add
>>>
>>> *default date=2010.03.28.06.00.00
>>> # here be dragons
>>>
>>> to your ports-supfile. But how do you tell when it's safe to remove?
>>
>> Warren:
>>
>> That makes no sense.
> ...
>> But that's not the point and never was.
>
>> The point is/was, or so I thought when writing my original post, that
>> recent upgrade cycles have been, shall we say, less than encouraging
>> and that, instead of getting better, the situation seems to be getting
>> worse each cycle, with multiple ports broken because the s/w _they're_
>> dependent on is broken or incompletely tested or, well, you pick a
>> reason. That should NEVER be and updates should not be announced
>> until there's some assurance that Joe User - who may be a home user or
>> an admin somewhere or anybody from naive to experienced - can reliably
>> do an upgrade by following the instructions in the handbook.
>
> That's why I suggested using a cvs date. When you know the date of the
> breakage, you can travel back in time and buy a lottery ticket!
>
> If entries in UPDATING were strictly formatted, an automated tool like
> portaudit could do things based on them. But it's not, so forget that.
>
> Sometimes things just suck, and then they get better. Yesterday, a
> bunch of ports were broken by png changes, today all of the ones that
> were broken (here) now work. In less than 24 hours. As suckage goes,
> it wasn't very bad for very long. If you hadn't updated your ports
> until today, or maybe tomorrow/next week/fall, maybe you wouldn't have
> even noticed.
>
> Of course, there's more big changes coming up...
>
> --
> Warren Block * Rapid City, South Dakota * USA

Point taken.

But the question then arises - if the "repairs" occurred within 24 hours of
the release, could that release not have been delayed by those same 24
hours in order to prevent the observed breakage? OK, immediate thought is
that the breakage and the consequent kvetching is what led to the repairs;
dunno if that IS the case or not, but it seems to me to be beside the
point. For that, see above or my earlier posts.

For those others who've replied with a "I never" or a "you should", I agree
that some of the never-do's are most appropriate to a production
environment, which my systems definitely are NOT. I don't insist on
bleeding edge anything - which is fortunate, since FBSD often lags what's
found on the various linuxes or elsewhere in *ix-land (and which is, IMO,
a good thing, overall). The same is true, to a more limited degree, to
the "shoulda's" - what I've done for the last mumble years has worked well
for me, although maybe I shoulda tracked the subscription mailing lists
or, just on general principal, waited a week or so before attempting to
update my ports.

That's all well and good, but begs the question: if, as the last several
port-upgrade cycles have more than amply demonstrated, the system is so
fragile that the average user (is there such an animal in FBSD-land?) must
wait for days/weeks after the ports tree is updated before he can reliably
update the ports on his system, then might it be that the process is
broken? Might it not be a worthwhile exercise for ports-manager to look
at a different model? As I've said repeatedly, I don't have an answer.

Bob Melson

--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
Nothing astonishes men so much as common sense and plain dealing.
Ralph Waldo Emerson

From: Warren Block on 29 Mar 2010 21:37
Bob Melson <amia9018(a)mypacks.net> wrote:
> On Monday 29 March 2010 14:19, Warren Block (wblock(a)wonkity.com) opined:
>>
>> Sometimes things just suck, and then they get better. Yesterday, a
>> bunch of ports were broken by png changes, today all of the ones that
>> were broken (here) now work. In less than 24 hours. As suckage goes,
>> it wasn't very bad for very long. If you hadn't updated your ports
>> until today, or maybe tomorrow/next week/fall, maybe you wouldn't have
>> even noticed.
>
> Point taken.
>
> But the question then arises - if the "repairs" occurred within 24 hours of
> the release, could that release not have been delayed by those same 24
> hours in order to prevent the observed breakage?

I don't know, but would expect private tests to have been run before the
png commits made it out into the real world. Is there an offline
tinderbox for all the ports? I thought so, but there were a lot of
broken--but easily fixable--ports.

There is something that can be done to ease big ports changes.

First, take it as granted that ports maintainers and committers are
doing everything they can.

What else is needed? More testing, and at least some of that can come
from interested individuals.

For example, the xorg update last year. I knew it was coming, and
contacted Robert Noland and offered to test ATI video drivers. I have a
variety of ATI video boards and wanted to do what I could to make sure
that they would work. At the same time, this would mean they'd work for
others. So I did some testing and shared results, nothing particularly
difficult. Some problems were discovered, Robert fixed them. I had
some hardware that Robert did not, too, and I think it helped.

At present, there's a test version of the new xorg update which some of
us have been trying. Don't know exactly how that would work with the
png update, since most people don't have the hardware for a full ports
tinderbox. But I'm sure if enough people offered, some system could be
worked out.

--
Warren Block * Rapid City, South Dakota * USA
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Stale BINDings
Next: NYC LOCAL: Tuesday 30 March 2010 NYLUG Hackfest