On Sat, Mar 03, 2001 at 01:41:58PM +1100, Brian May wrote: > Call me overly optimistic, but I refuse to give up that easy!
I am happy to see this effort. I will support you on your way. The main problem is that we are locked up into an unpleasant situation. We can't follow strict policy as it is, because we would alienate our fellow developers (that's Jeff threat to start to file bug reports. I sympathise, but it attacks the leafs, not the root of the problem). OTOH, for the very same reason, for many Debian developers this is not very important to resolve. I wished it would be possible to work this out in cooperation with the dpkg developers. It would make things so much easier if we would share a vision. I don't know if this is possible. Time constraints and priorities might make this unfeasible. In any way, I encourage you to integrate the dpkg and apt developer, the ftp archive maintainer (dinstall) and the autobuilders early into the process. All these people must incorporate some changes to make the system work at the end. One problem might be that few people are aware of the size of the problem. It might be convincing to start a list of selected packages where bug reports would have to be filed if no action was taken, and what type of bug it would be: Change Architecture: all into Architecture: i386 m68k alpha ... (list all linux arches here) for package: makedev, kernel-source-* Change Architecture: any into Architecture: i386 m68k ... (list all linux arches here) for package: (long list of highly linux specific configuration, admin and hardware utilities). Maintainers will better realize the relevance of the proposal if they see their own package in the list ;) > FINAL NOTES: > > Of course, I am speculating a lot here, as I need to do the short term > step 1 and 2 first. (I can't remember what was discussed now). (Already mailed this part in another message) Please also include the following into your lecture: http://lists.debian.org/debian-dpkg-0102/msg00053.html Essentially, there are thee subproblems: 1. Build-Depends: don't understand hurd/linux ("platform" in Phils words). 2. Architecture: is insufficient in the ways described elsewhere 3. Depends: doesn't understand architectures at all. The feature in 3 is not strictly necessary, but we might invent some mechanism to make it easy for people to have different control files, so they have a reference implementation on how to do that, which we can link in bug reports. There will have to be plenty bug reports on this to make this worth the effort. I can probably do that. However, if the dpkg developers want the feature in 3, I am all for it. It makes things a lot simpler. 1 should definitely be fixed. We have time until the first Hurd port to another arch but i386 takes place, but we should fix it prior to this. We can draft a simple proposal to policy, get it included, and then tools have a lot of time to implement it (when they have, a bug report can be filed on libc, which is the only package currently using this, but more to come). 2 is the thing you talked about. > When I finish any step, I will post the results here, so others can > pick on any mistakes or other problems (as there probably isn't any > point to posting on debian-policy until everyone here is happy first). Thanks. > COMMENTS? > > The way I see it, with a formal proposal, we a lot better of then with > no formal proposal. Yes. My goal was to get some input from certain people on this, but I failed. I wish you more luck. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
