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

Re: Sources vs Packages files



Marcus Brinkmann wrote:
> "unstable/main" of some architecture is the content of
> ROOT/dists/unstable/main/binary-ARCH/Packages

I have NEVER heard this definition of "main". It is highly inconsistant
with how policy uses the word. But fine, if that's how you want to
define it.. Just don't expect this definition of the term to carry much
weight with me.

> 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..

> >    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.

I happened to decide to use a format consisting of an ar containing two
tar files. I had no idea people would find this so confusing, and keep
conflating udebs with debian packages, and expecting them to behave 
and be used in similar ways. Show some mental flexability, people.
Sheesh.

Again: UDEBS ARE NOT DEBIAN PACKAGES.

> 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.

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.

> 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).

A quick grep doesn't show any mention of debian-installer at all in the
wanna-build source.

> 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].

Thus introducing a whole raft of special cases in dselect, apt, dpkg,
deity, and every other tool that deals with Packages? No thank you.
(I thought you _disliked_ special cases?)

What about the fact that debian-installer needs to download its Packages
file to download the rest of itself, and needs to do this with reasonable
speed and in a memory constrained environment with no mass storage
available? Having a seperate Packages file makes this possible for us.

> 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, used a different filename extention,
and threw policy out in the dustbin when creating them because ... (well,
I've shouted it twice now, I'm not gonna again).

> [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.

I do it every time I install debian.

-- 
see shy jo, moving and extremely stressed, who is beginning to agree with
            Glenn -- perhaps simply dropping udebs on sourceforge would be
	    less bother than all this pointless bickering. Perhaps we should
	    use urpms too?



Reply to: