simple proposal to illustrate (was: Re: Sources vs Packages files
Hi,
At the end of the mail, there is a very concrete proprosal of a small change
which would achieve what I want to have. It might not be ideal, but it
should at least illustrate what I mean.
On Fri, Apr 20, 2001 at 01:02:04AM +1000, Anthony Towns wrote:
[about debian-installer]
> It's something truly different that we've never dealt with before. Trying
> to force it into some mechanism we already have without considering how
> they're not appropriate would be awkward and break things.
I concur entirely. But they are build from source packages which are *not*
in the debian-installer part of the archive, but in the top level.
How does katie (or dinstall, or what it is called) decide if it should
install a file in the regular archive or in the debian-installer section?
Is the package name space of debs and udebs the same?
(It must be to meaningfully merge the Packages files and list them in the
Sources file).
Those are only some of the concerns I have. Although you restated that udebs
are something completely different, they are tightly coupled to the regular
archive in several ways. In my point of view, it makes sense to either
accept this binding and make it official by some interface to be determined.
(Especially not overloading the "Section" field for this, if this is what is
used to make the discrimination).
Note that I am not trying to look at the obvious similarities (like that we
use the same tools to process debs and udebs, and that the archive
organization is the same. I am only looking at interactions between
deb-space and udeb-space).
> > Obviously not-Debian packages are not suited for installation on a Debian
> > system "automatically".
>
> Correct. And the way this is indicated is by segregating them into a
> completely separate packages file.
I don't question the usefulness of this (I did propose in the earliest mails
to merge them in the main archive. I do not any longer, after Joey convinced
me easily that they don't belong there).
However, I question the way the new feature of "subdirectories with
something different than debs" is integrated into the packaging system.
I am not overly concerned about archive organization. But I want
to know which Packages files belong to a Sources file by looking at the
DIST, ARCH and at the content of the Sources file. I have a concrete
proposal about this at the end.
> > > > People often say that Debian strives fro technical excellence. I can't see
> > > > technical excellence in the introduction of the debian-installer
> > > > subdirectory. I raised this issue because I think we can do better.
> > > Sure we can. But the problem here isn't that the structure of the archive
> > > is wrong, it's that the autobuilders haven't been particularly well
> > > organised and consistent across architectures.
> > This is the wrong way around.
>
> The work around you seem to be hinting that you'd like is some sort of
> stable url where all the appropriate Packages files are cat'ed together so
> you can run quinn-diff on them and not have to think about things anymore.
The url doesn't need to be stable, but it should be possible to derive it
from other information. And I don't use quinn-diff, but my own algorithm
(which is more accurate in one border case, except if quinn-diff has been
fixed in the meantime. See BUGS section of quinn-diff man page).
> Everyone else involved considers this an ungainly hack, and would rather
> work on making a more useful infrastructure to help out autobuilders,
> which is being used by just about everyone but hurd now.
I have doubts that I was successful at communicating what I expect, because
I can't understand why you don't think a modification to automatically track
isn't a more useful infratstructure to help out autobuilders. Here is a
concrete proposal (out of the blue, but it might just work).
List udebs in the "Binary:" field of the Sources file not with their name
NAME, but with "debian-installer/NAME".
(Or, alternatively, list udebs not in the Binary: field at all, but in a
different field, like "New-Binary: [debian-installer] NAME" to remain
backard compatibility).
This would instantly provide me with the information I need. When parsing
the packages file, I could look at all "SUBDIR/" prefixes in the Binary:
fields, and fetch those additional Packages file. (It would also keep the
name space seperate, but it si questionable if this could be exploited
easily. Consider BTS etc).
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: