On Tue, Dec 09, 1997 at 02:10:35PM -0500, Brandon Mitchell wrote: > On Mon, 8 Dec 1997, Adrian Bridgett wrote: > > > On Sun, Dec 07, 1997 at 06:20:27PM -0600, Marcelo E. Magallon wrote: > > > > > it's the obvious way... create another architecture tree, binary-i586 > > > (gosh, that going to hit hard on the mirror eventually. Time to get yet > > > another harddisk for the Debian mirror ;) It's just a minor (I hope) > > > modification to dpkg: > > > > I agree with Andreas that symlinks are unnecessary. We really need a way of > > keeping the control file the same (apart from Architecture:) and telling > > dpkg to take packages from the binary-i586 directory if they exist. I don't > > know the internals of dpkg/dselect/deity at all - how workable is this? > > Adrian, could you respond to my follow up to Andreas's post: > http://www.debian.org/Lists-Archives/debian-devel-9712/msg00354.html
Ah, on re-reading my first sentence, I think I should have added "in theory" :-) I agree with your point that having hundreds of symlinks from binary-i586 to binary-i386 allows us to use the current tools with very little changes. [insert message here] --message-- Andreas, Can you compare: debian/dists/unstable/hamm/binary/admin/ debian/dists/unstable/hamm/binary-all/admin/ and explain how we should get rid of the symlinks in binary (which is itself a symlink to i386)? I'm basically proposing another platform which is backward compatable. Therefore, make the directory for the platform, and while we don't have a package of the new type, use the old type. However, I still haven't heard about the possibility of getting dselect's ftp to look at binary-pent or at the compatability of pentium clones. If we put everything in the same directory with different provides, etc, I feel like things will get really confusing, and defeating the purpose of having different directories for different architectures. --end-message-- > I feel I made myself a little clearer on the symlink idea in this post. > The problem with yours is that you are suggesting a fairly large overhaul > of dselect's ftp method (dpkg doesn't do the ftping), when it could be a > simple 1 line change from binary-i386 to binary-i586. I admit the > symlink solution is ugly, but it requires the smallest development time > (considering the ammount of time we need to spend on libc6, this is a > good thing) and has the smallest effects on the end user (from the choices > I've seen at least). A good time to do this right will be with deity, but > that will be a while. And the conversion from what I'm suggesting now to > a deity way will probably be painless, remove the symlinks, point deity to > binary-i586 first and have binary-i386 as the second choice. We have far too many symlinks around the place - we really shouldn't need any (or at least not many). However as you say, deity will hopefully solve these problems. IMHO it's better to rearrange everything to a "future-proofed" design, than to keep adding sections here and there. Over time the hierarchy has improved - we now have dists/(un)stable, each with main/contrib/non-free sections. Since we (hopefully) don't have too long to go until hamm is released, maybe we should drop this idea now, and _then_ perhaps look at the current directory structure and how to refine it (remove symlinks etc) - which must also mean that the tools *support* the new structure. Obviously Guy Maor should have (final?) say in this - being the site maintainer. Another reason for (temporarily) dropping the idea is that there won't be many packages that would gain sufficient performance to warrant being repackaged - although Xemacs springs to mind. Perhaps for this select group of packages we could just make ones like "Xemacs-i586, conflicts xemacs, provides xemacs" or whatever? Adrian email: [EMAIL PROTECTED] | Debian Linux - www.debian.org http://www.poboxes.com/adrian.bridgett | Because bloated, unstable PGP key available on public key servers | operating systems are from MS -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
