Re: Sources vs Packages files
On Wed, Apr 18, 2001 at 02:09:32AM -0500, Joey Hess wrote:
> 2. in the main archive
>
> Well, er, define "main".
"unstable/main" of some architecture is the content of
ROOT/dists/unstable/main/binary-ARCH/Packages
In general, the content of the distribution DIST of arch ARCH is:
ROOT/dists/DIST/binary-ARCH/Packages
the sources for DIST are:
ROOT/dists/DIST/source/Sources
this was true until the debian-installer directory was introduced. This is
some new informaton which can't be logically derived from DIST/ARCH value
pairs. To get the correct state of a distribution, you now need to know the
extra information that there is some strange
dists/DIST/debian-installer/binary-ARCH/Packages
file which cntent has to be considered as well.
This is troublesome as this rule is not consistent: The debian-installer
area does only exist for unstable/main currently. So the exact names of
subdirectories to consider depends on the DIST and on current practice: We
have no way to automatically track such extra directories in our tools.
The pool area has nothing to do with it. The pool is a tool for internal
ftp archive organization. It can not be considered by distribution tools.
I want something that can determine the full list of Packages and Sources
record entries from DIST/ARCH pairs that works for past, present and future
Debian archives. Note that "past" and "future" in this sentence prevents the
simple "add debian-installer if DIST is unstable/main".
> As the word is typically used, they are in main. Do you really want
> to confuse users by letting them see these things in dselect by
> default? Seems very silly.
You are already confusing them by producing them from the same source, and
not including them in the standard place of Debian packages.
> > Either solution would be fine for me. But it would be important to have a
> > decision rather sooner than later, as either this or a work around is needed
> > to make the autobuilder pick the udebs binaries up (at least for turtle).
>
> I think your autobuilder is making invalid assumptions. All the others
> worked fine, or with at most minor modifications like adding ".udeb" to
> a list of file extentions.
This is not true. My autobuilder builds the udebs fine, and uploads them. It
doesn't fetch the debian-installer/binary-ARCH/Packages file though, and
thus it doesn't notice that the udebs are installed. Of course I can add a
hack to do that. But I feel that such a hack is really gross, and it is
because the introduction of unstable/main/debian-installer is gross and
inconsistent with what Debian did before it was introduced.
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.
BTW, I would prefer to implement a precise defined standard in the autobuilder
which only relies on defined interfaces to the Debian archive. Such a
standard doesn't exist: The ftp admins implement new features ad hoc. So all
assumptions I make in the autobuilder are derived from what seems to be
correct from past experience. The debian-installer subdirectory is such an
ad hoc feature, there is no way one could have prepared for it (I haven't
checked wanna-build, but I assume they implemented a hack like I describe
above).
I have seen good a good argument against a seperate source area (same source
for udebs and debs). I have not seen a good argument against inclusion of
udebs in main: That they are confusing to new users is something that can be
solved in the front ends by simply not presenting them to the users[1]. That
they conflict with Debian policy can be solved by amending Debian policy
appropriately. It seems that people wanted to avoid the resolution of such
inconvenient conflicts by changing the ftp archive structure to "move them
out of the way". But problems are not going away by hiding them, and the
change to the ftp area is breaking other assumptions, which were fine (and
which still make sense to me).
Now, if you think we should have an interface for such sub directories, I
could live with that. But I still think that the need for such extra
directories is not existing: udebs could be in their own section "installer"
and all Packages in this section could be ignored by front ends. This is one
approach, there are many others.
Thanks,
Marcus
[1] We need a way to deal with such things in front ends anyway: Nobody can
browse the full list of packages anymore. It takes hours.
--
`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: