Re: Pretty please: no more lower-case macros !!!

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Matthew Dillon wrote:
:
:>     Which macros are you talking about, specifically?
:>     I am not particularly fond of #define macros either but as far as I
:>     know we have not added anything non-standard visible to userland.  If we
:
:
:    At line 261 of /usr/include/net/route.h you have:
:
:#define        sa_dst        rti_info[RTAX_DST]
:
:and other seven similar macro definitions.
:
:	These macros have broken net/quagga and net/zebra by the mechanism 
:described in my initial message of this thread and they might also break 
:many other packages.

    Excellent.  Jeff just fixed that.  If you see any more definitely
    report them.

:>     DragonFly is going to break a lot of FreeBSD ports, period.  DragonFly
:>     is not FreeBSD.  There will be a focus on the ports/packaging system 
:>     later on, but that isn't the focus right now.
:
:	You are right and what I like about your project is that you are not 
:afraid to make real changes.  Nevertheless, you must keep in mind that 
:you cannot describe DragonFly as anything near production-ready while a 
:large number of essential ports are broken.
:
:	I have around one hundred FreeBSD production computers, but with all my 
:goodwill I could not find enough of the ports that I need to be working 
:at this time so I could not switch even one of the servers to DF.
:
:	As other people have already said, the greatest FreeBSD asset is the 
:huge ports collection.  I do not see any reason to break the ports 
:without a serious motivation.  These macros could have been easily 
:avoided and for the large deletions that have been done in many 
:networking headers a more gradual strategy could be adopted.

    The problem here is that we cannot fix every port every time we make
    a change, and quite often the build failure is not our fault but
    instead an error in the port (not following standards, making 
    incorrect assumptions, or hacked specifically for FreeBSD), or the
    port is accessing some internal kernel data structure that has changed,
    or something equally silly.  In otherwords, the issue is not necessarily
    fixing or reverting header files changes, but instead fixing the port
    itself to conform to the standard.  Other errors, such as Jeff's little
    header file snafu, are simple mistakes, but since nobody can foretell
    the future it's virtually impossible to catch those kinds of errors
    before-the-fact, and way way way too much of a burden (and too huge a
    mess) to try to conditionalize every little change.

    We do not have the manpower to maintain thousands of ports and still
    be able to make progress on DragonFly's goals set.  We could spend 100%
    of our time making ports work and still not get them all working, because
    new versions are constantly being released of things.  We would wind up
    spending 0% of our time on the kernel and utilities and then there 
    wouldn't be much of a point doing DragonFly at all.

    This is why are current ports focus is more on precompiled packages
    then on directly built ports.  And our eventual focus will be the same,
    simply because it is not possible to make progress on the system and
    maintain all the ports at the same time.

:	For example, you could put the items scheduled for deletion from the 
:standard headers under conditional compilation and allow for some 
:limited time the ports to be built with or without them and announce 
:some roadmap for the deprecated features so whoever is interested in the 
:ports will be able to make the required changes before those features 
:are removed from DF.

    This would only result in a much larger burden on the developers.
    Look at the burden we already have dealing with GCC-3.x ?  It isn't
    even the default yet it is responsible for a huge number of postings
    and bug reports.  GCC-3.x is important... it's the future after all,
    which is why we have to tolerate dealing with its issues, but we can
    only do so much of that before run out of manpower.

    And that's the problem... when you give someone a choice it actually
    triples the amount of work required to maintain the system rather then
    simply doubling it because now when someone reports a bug one winds up
    having to figure out exactly which set of choices they used in order
    to figure out what the problem is.  It adds and extra step, and we can't
    really afford that.   So conditionalizing header files is just not in the
    cards.

:	As it is now, I only see that a lot of things have been deleted from 
:the standard headers, but I know neither what other things are planned 
:to be deleted nor what is supposed to replace the deleted items, so I 
:cannot help in making the appropriate changes in the ports.
:
:	Maybe if you could release some documents about your plans regarding 
:the userland interfaces, it would enable more people to contribute to 
:restoring the ports collection to a working status.
:
:	Best regards !
:

    The user visible header changes are primarily based on the various
    UNIX standards out there.  e.g. then Open standards, SUSEv3, etc.  That
    isn't really relevant to the ports issue because most ports are written
    for particular platforms (like Linux), and often make assumptions that
    do not particularly follow the standards.  Again, it is not possible to
    make progress on standards conformance and also keep all the ports 
    working.  Even FreeBSD has a hard time keeping their ports tree 
    compileable, and they have something like 5 times the number of people
    working on the ports tree as us.

    It isn't that ports aren't important, they are, but there is currently
    no viable solution for DragonFly that allows normal development towards
    its goals set to proceed at a reasonable pace.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>