Re: Sources vs Packages files
Hi,
Joey, your shouting (as unpleasant as it is) seems to point at a certain
level of turmoil. There is no need for that. I am not against udebs, and I
don't care where they are stored and how they are defined. I am just
interested in a nice way to find out what package I need to build and what
package is up-to-date, so that udebs will always be up to date on the Hurd
architecture. Likewise, I would prefer a mechanism which can automatically
pick up odebs, fdebs, sdebs, tdebs and mdebs when they appear.
This is really all I care about, and I would appreciate if the discussion
would focus on that, and not on debian policy, how unstable/main is defined
or various other details that distract from this.
On Wed, Apr 18, 2001 at 02:22:59PM -0500, Joey Hess wrote:
> > 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".
>
> I can make no such guarentees, I guess you need to talk to the ftp
> admins if you want such a solid guarentee. If they had made this type of
> guarentee in the past though, we probably wouldn't have pools now..
Pools have nothing to do with it. The physical location of a package is
listed in the filename section of the Packages files record entry for
this package.
I don't expect from you to do anything about it. But such guarantees could
be made without the debian-installer sub directory. They can also be made if
there exists a file "dists/DIST/subdirectories" which lists debian-installer
(just as an example interface). They can also be made in a trillion other
ways.
> > > 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.
>
> THEY ARE NOT DEBIAN PACKAGES.
Ok, so they aren't. So we now have the situation that Debian source packages
are used to build Debian Packages "byhand" files and udebs, but no interface
to find out what is installed/listed where and which version it has.
This doesn't make the situation any better. By luck(?), the format of the
Packages file in the debian-installer section is very similar to the frmat
used for real Debian packages, and I like it that way.
However, by denying that udebs belong to the set of Debian packages for a
distribution, the situation is worse: We now have a full set of formally
unspecified packages. (If they are formally specified, please provide me a
reference to the docs, so I can check if they give me the information I
need).
> > 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.
>
> Well, make a better proposal. I have heard nothing better.
What is a good proposal depends on how much extensions to Debian source
packages we expect in the future. If debian-installer is all we ever want to
care about, then special casing it is as good as anything. But if the next
subproject in Debian decides to have Debian source packages build something
that are not Debian packages (let's call them odebs), and install them in
debian-obnoxious, with a similar setup as debian-installer, then a pattern
arises and it would be a good idea to have a common place to list such
extensions.
How much of this should be formalized depends also on the consistency
between such sub projects. If odebs don't follow the deb naming convention,
and the conventions for the Debian distribution, and the convention of the
Packages file, it will be very difficult to treat them in autobuilders etc.
> We discussed this issue for over a month before arriving at the current
> solution. It _stalled_ debian-installer for that month, quite badly. I
> would have certainly appreciated your comments at that time, but after
> the fact it seems like so much whinging to me.
I was not aware of the issue or I would have spoken up earlier.
> A quick grep doesn't show any mention of debian-installer at all in the
> wanna-build source.
I would look in quinn-diff. quinn-diff has to determine if a certain source
package is out of date or not. For Debian source packages building (just?)
udebs, it can only do so by the version number listed in the Packages file
of the debian-installer area.
In general, the main problem I have with this is the following:
"Giving a Debian source package, verify if it needs to be build or if it is
already up to date on this architecture."
This requires a careful comparison of the Packages and Sources file
content, and is only possible if we are clear on where to get all the
version numbers from. For byhand installed files, this is not possible.
For udebs (and hopefully odebs, too), it is possible. We just have to have a
clear idea on where to find the information.
> > 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
>
> No, we moved them out of the way,
Not completely though, as you still build from the same source. For me as a
porter, this is not out of the way. The simplest solutoon would have been to
fork all required sources, this would be really out of the way, and would
isolate you from all policy concerns as well as from all archive format
problems.
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: