Sorry for the late reply. On Tuesday 15 April 2008, Guillem Jover wrote: > On Mon, 2008-01-14 at 19:29:58 +0100, Raphael Hertzog wrote: > > On Fri, 11 Jan 2008, Joey Hess wrote: > > > Determining a file's type from its extension is "weak and specific"? > > I'd say generally, yes. But it also depends on the type of file. I'd say determining the main type (debian package or not) by examining the contents or signature and then determining the subtype (deb or udeb) by extention should be perfectly fine. > > At that point it's ok I guess. But for example when dpkg-deb creates > > the package, it would be nice if it could just find out the right > > extension to use. > > There's also the checks and warnings dpkg-deb could do or issure on > what is an acceptable udeb, in a similar way it's done right now with > a deb. Or lintian. But dpkg-deb could do that by getting a correct option passed (as is effectively done now) and lintian could do it by checking the file extention (surprise: also the way it's currently done). > > Guillem, what other use cases did you intend for Package-Type: udeb in > > the binary itself? > > In my mind udeb form a different distribution than normal deb, even if > the udebs are currently built on a normal deb system. So normal users > should not be able to (easily) mix them (w/o using a dpkg force option). Correct. That's why they already have a completely separate Section:. > The fact that we have to overload the package name to denote a udeb when > there's a deb with the same name (libfoo-udeb), this is fine as a > workaround but the XB-Package-Type field fixes that in a cleaner way, > and would allow dak to be able to distinguish them nicely. > > This last point affects the dependency information, and the need for > the additional Provides mapping to the non-udeb packages. I actually prefer the separate names as it is absolutely not true that there is a one-on-one mapping from regular library packages to library udebs. For libc for example we have separate library udebs for lib-nss-* files, which the regular lib does not have. Therefore a separate handling of dependencies is required anyway which is helped by having different names. > The current places (related to d-i) where this field appears or can end > up, seems to be: > > * udeb: might contain the field inside the control.tar, compressed. > Size diff on a dummy package w/ and w/o the field is +- 10 bytes. > * status: udpkg does not copy unknown fields there (P-T is unknown). udpkg is not the only thing that creates the status file; it's partly generated during the build of D-I images. > * Packages: contains the field, might end up uncompressed on disk. > > Given this, I propose a short-term space saving compromise. It seems > redundant to include the field on Packages files which will only > contain the same type (it might make sense to include those when > mixing types, though). This would only leave the fields in the > compressed control.tar inside the udeb. This would need fixes for > dpkg-scanpackages and apt-ftparchive, I'd be fine preparing patches > for both. Also apt-ftparchive from ftp-master would need an update, > we could discuss that with the ftp-masters. Why do you keep insisting that the field should be included inside the udeb? My opinion remains that we have no need or use for it there. This seems like a really complex solution this short before the release of Lenny, requiring too many changes in too many places and the cooperation of too many people. I could see such a solution being implemented post-Lenny, but for now it seems to me there is a much simpler solution: keep the current situation as it is with XC-Package-Type and don't include the Package-Type field anywhere. > Longer term space saving benefits could come from making udeb a first > class thing, and being able to remove all '-udeb' package name suffixes > and matching Provides fields. But this and other things could be > introduced incrementally as long as the fields are there. This needs very serious discussion and should probably only be done in combination with a total revision of how udeb dependencies are expressed (as currently we cannot express all (versioned) interdependencies there actually are because it would interfere with the functioning of the installer, especially That discussion should be done at the start of a release cycle, and not at its end. My impression is that you both have only a very limited understanding of how udebs are actually used and what limitations they bring with them. I don't in any way blame you for that, but it does mean that your proposals are somewhat out of touch with reality and, as mentioned before, the current time is _not_ the time to make major or even minor changes in something that basically just works. Please: just fix the regression you introduced. Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.