Re: smarter way to differ architectures needed?
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 brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: