* Adam Heath <doogie@debian.org> [030625 09:57]:
> On Mon, 23 Jun 2003, Bart Trojanowski wrote:
> > Sure, the requirement idea is grant. However, it does not solve the
> > issue of coexisting 32 and 64bit packages. When using my laptop I want
> > to install as many i686 packages as possible, buy on the server I want
> > to install amd64 packages. Installing i386 packages is a waste of the
> > CPU features.
>
> Sure it does. Dpkg installs packages, checks deps, etc. That is all it does.
> It is up to frontends to select the appropriate package.
Debian packages contain dependencies on other software packages that
need to be present for said package to run.
You can look at hardware dependencies as being similar requirements,
however no front-end (other then perhaps a screwdriver) can be used to
fulfill such dependencies.
That is why I believe this relationship should be covered by the
architecture.
> > Making all packages compiled for i*86 and amd64, be *_i386.deb's is
> > really not a good idea. There is no way for a 32bit binary package to
> > coexist with a 64bit package, since they are named the same. Sure their
> > Dependencies differ, but that is not clear until further inspection.
>
> Are you suggesting that we encode the entire dep list(depends, pre-depends,
> conflicts, suggests, recomments) into the filename?
Of course not. Those things do not define the architecture.
If a package is exim4, it is always exim4 regardless of what compiler
and compiler options were used to build it -- it's dependencies do not
change, nor do pre-depends, conflicts, suggests or recommends. However
with hardware dependencies involved, I no longer know if I can install a
package by looking at the filename.
If dpkg is not to support sub-architectures (like amd64, etc) then the
same package name, say coreutils_5.0-4_i386.deb, could potentially
contain different hardware dependencies.
I believe the package name is misleading since this particular
coreutils_5.0-4_i386.deb may not be installed on i386 since it was built
with the intent of use on DEB_HOST_GNU_TYPE=x86_64-linux. The filename
containing i386 seems counter intuitive.
We can already see this in the kernel packages. The architecture is
i386 yet the file is named kernel-image-2.4.20-3-k7_i386.deb. I predict
that more packages will emerge containing the sub-architecture names in
the version tag of the package and the architecture set to the base
architecture.
> > That's not very intuitive for the end user. I am not sure how many
> > users know that they have MMX or even worse the CMOV instruction. And
> > how would you distinguish packages for CMOV-capable and non-capable
> > packages... say, after building them with dpkg-buildpackage?
>
> Again, frontends can display it however they want. Users aren't really
> supposed to deal with low-level dpkg, nor debs.
That is true.
However sub-architectures benefit the Debian developer as well.
- clashing filenames will require a change in dpkg-buildpackage
- one can no longer download a file and know if it will run on their system
- developers don't always use front-ends
- not all deb's are in the Debian archive
- everyone know what their CPU architecture is
- not everyone knows which pentium remake introduced CMOV, SSE or MMXEXT
- architectures map to compiler (gcc) architecture/cpu settings
- direct mapping of autoconf architectures to Debian architectures
And although it's not a very important point for Debian.
- the sub-architecture approach has worked well for other distributions
> > I miss the point on how having SSE prevents your CPU from having MMX?
> > My AMD CPUs certainly support both.
>
> Bah, stop being optuse. It was an example, nothing more.
Fair enough, but there is no need for insults. I would prefer to be
convinced...
Sincerely,
Bart.
--
WebSig: http://www.jukie.net/~bart/sig/
Attachment:
pgp0zX2ZskCvg.pgp
Description: PGP signature