[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:
> 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]
   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
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?


email: adrian.bridgett@poboxes.com       | 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
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: