Re: Pretty please: no more lower-case macros !!!
: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@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 10 之 14 篇)：