Re: pentium specific packages
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:
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
[insert message here]
Can you compare:
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.
> 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
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?
email: firstname.lastname@example.org | 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
Trouble? e-mail to email@example.com .