DragonFly bugs List (threaded) for 2005-01
Re: Pretty please: no more lower-case macros !!!
Matthew Dillon wrote:
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.
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
DragonFly is going to break a lot of FreeBSD ports, period. DragonFly
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.
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.
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 !
is not FreeBSD. There will be a focus on the ports/packaging system
later on, but that isn't the focus right now.