Kris Kennaway explained in 4 points why a proposal to introduce a new package system is doomed to failure.
In particular he says: > "I think your current proposal falls short on points 2) and 3). In > particular, I don't see where SQLite is necessary to solve any > problems we are currently facing, and your proposal conflicts with > existing work." Existing work consists in integrating metadata in a Berkeley DB database, when new project would like to integrate them in SQLite database. Now existing software (portupgrade) has shown what can be gained by pushing all sort of unstructured data in a Berkeley base :-( In this same thread N arguments have been advanced by various people showing why using something more structured and formal like a SQL database would be beneficial. One of the most obvious being that the sqlite database can be edited as easily as a pure textfile using the sqlite3 program, or can be accessed programmatically from a lot of languages (C, perl, python, ruby) using well known and well tested libraries or connectors. Since sqlite is public domain, there is no licence objection to bring it in FreeBSD. Moreover it is a small program and which could be very useful to a lot of users and for a lot of alternative uses. As a consequence the "high bar of entry" and the "proof of necessity" seem to me an unreasonably stringent condition. Because the problem to be solved is not the "collapse under its own weight" of the proposals, but the collapse of the FreeBSD ports system. Someone (i think des) has said not long ago that Debian or Debian like systems were easier to maintain than FreeBSD. This is an understatement. -- Michel TALON _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
