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

Re: New `dpkg --print-subarchitecture' option

On Sat, Sep 23, 2000 at 12:14:12AM +0200, Wichert Akkerman wrote:
> > Doing this just so that it is in a single place is unhelpful, we had this
> > situation (with the single place being dpkg). There are different purposes,
> > and those should be watched. For example, installation-architecture sits
> > perfectly in dpkg. dpkg-architecture fits perfectly in dpkg-dev (compile
> > time decisions). Sub arches are a run time issue, and debianutils isn't a
> > bad place for that.
> I'ld like dpkg-arch to be a runtime thing, sort of like config.guess I
> guess. update-modules, makedev and hwclock have shown that that can be
> useful. dpkg-architecture works great for compile-time decisions indeed.
> Naming might become a bit confusing though..
> > You need to explain this. How do you want to use it? If it ever becomes a
> > build issue, I agree it should be in dpkg-architecture. But without knowing
> > more (and I really would like to hear about plans involving dpkg and
> > architectures), I can't tell.
> Read your own proposal (I sure hope I didn't grossly misremember what
> you wrote in there. I need to write something about planned changes in
> dpkg I think to clarify things).

Ok, I think I slowly realize... if hardware and kernel (=architecture)
interfaces are realized by (probably) virtual "package names" (or an
orthogonal structure with similar provide and depends semantics), we need to
query dpkg(-arch) for the set of installed (available) hardware/kernel
interfaces, right? [this sentence is only so complicated, because I don't
want to imply the use of virtual package names for this, but the metaphor is
just too useful to ignore completely).

That's true, and when we go for this new scheme, the relationship between
dpkg and dpkg-arch becomes a hard one. I would be very satisfied with such a
solution, as you can imagine :)


`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server 
Marcus Brinkmann              GNU    http://www.gnu.org    for public PGP Key 
Marcus.Brinkmann@ruhr-uni-bochum.de,     marcus@gnu.org    PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       brinkmd@debian.org

Reply to: