Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
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 signature.asc Description: This is a digitally signed message part.
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
Hi, 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. Tell that to /var/lib/dpkg/info/*.p*. Those are just executables, exec(3) (or the kernel on most systems) will decide if it can do anything useful with them given their signature. Tell that to everyone who has run dpkg -i *.deb and managed to not accidentially dpkg -i *.a (both ar files after all). That's why the .deb files have a signature. I'd expect a bug report if dpkg would manage to install a non-deb .a archive. 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. Since dpkg-deb only has a directory as parameter, it would be nice to have the Package-Type: in the DEBIAN/control file there. Another possibility would be to add a new command line option to dpkg-deb, but the problem with that is that it's not preserved across unpack and repack. 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). 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. Would one of the above solutions be reasonable? Does it make sense to go that far just to be able to give the correct name automatically? 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). * 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. 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. Um, all I got from your communication on this subject was that you would make it an official field, not that you would put it *in* the binary package. --- Day changed Thu Jan 11 2007 01:01 braindmg joeyh: what was the rationale for having XC-Package-Type? I'd say it should be XB- 01:02 braindmg (also dak is not checking for it in the .changes, at least from this checkout from bzr) 01:04 joeyh braindmg: it's only used by debhelper 01:04 braindmg yeah I saw now that it understands X[BC] 01:06 joeyh or without the X- in svn 01:07 braindmg I'm thinking that if dpkg-dev starts understanding P-T it should better do something useful with that, and produce proper .udebs, but I'd have to check how debhelper will cope with that regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
Now that the dust around the major changes in dpkg has settled a bit, I hope
that you can find time to take another look at this issue.
The blocking issue for us (D-I team) at this point for switching from
XC-Package-Type: udeb to Package-Type: udeb is that it increases the size of
the control file.
Just as an indication of how serious we take the memory usage of the
installer, I can give you this example. For Etch the installer required a
minimum of 72 MB to complete an installation with all translations enabled
and 32 MB for a bare minimum install on i386. For Lenny we have implemented
various changes to reduce memory usage and this has been reduced to 42 MB
(probably even less now, but that needs testing) and 28 MB, despite the
fact that we've also increased the total functionality of the installer and
that the kernel and libraries in general have increased in size.
Sure, we can gain memory in other places too (and we have in the mean time
reduced the long descriptions of some udebs), but we do absolutely try to
avoid increasing memory use when not needed and we would appreciate if you
took our concerns with regard to that seriously.
I have just taken another look at the issue and below is a patch that could
possibly solve the issue. It suppresses the inclusion of Package-Type for
the control file, just as was already done for Homepage.
I'm not sure if that is an acceptable solution, or that this will interfere
with dh_builddeb (or rather dpkg-deb) later. AFAICT it does not, but please
check.
Note that we still consider this a serious regression and that if this mail
does not result in a resolution, or at least an acknowledgement of our
concerns and serious effort towards a resolution, I intend to escalate the
issue to the Technical Committee.
Cheers,
FJP
$ diff -u /usr/bin/dpkg-gencontrol dpkg-gencontrol
--- /usr/bin/dpkg-gencontrol2008-04-12 14:52:05.0 +0200
+++ dpkg-gencontrol 2008-04-12 14:51:59.0 +0200
@@ -269,6 +269,7 @@
if ($package_type eq 'udeb') {
delete $fields-{'Homepage'};
+delete $fields-{'Package-Type'};
} else {
for my $f (qw(Subarchitecture Kernel-Version Installer-Menu-Item)) {
warning(_g(%s package with udeb specific field %s), $package_type,
$f)
signature.asc
Description: This is a digitally signed message part.
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
On Fri, 2008-01-11 at 01:24:33 +0100, Frans Pop wrote: On Friday 11 January 2008, you wrote: Joey, I don't think that that the Package-Type field ending up in the binary package can be qualified as bloat given that except the filename and the origin of the file, udeb can't be identified as such. I'm sorry, but I agree with Joey. There is absolutely no reason why we need the package type in the control file for udebs. They are already 100% identifyable by both section and extention. Well then there's also the argument that there's no point in having it in the source control either, it could be inferred from the section. But those seem quite weak and specific ways to do so. Anyway, I don't think that'd be clean, and we might want to use that field for other package types in the future (translation debs, or debugging debs come to mind). The way this was implemented basically just ignores the only current official user of the package type field, I mentioned I'd implement it that way one year ago (or so) on #d-b, and no one seemed to oppose, and I requested comments on the patch implementing this again on #d-b few days before committing. That does not mean that decision could not be changed, but I don't see a good reason to do so, the current implementation seems cleaner anyway. and is thus not policy compliant. The initial udeb support seems to have been implemented and deployed in an ad-hoc way, overriding[0] dpkg, which is perfectly fine, as that's how a lot of things are implemented and deployed in Debian. But I'd not go as far as calling that policy. regards, guillem [0] I'm not sure this strictly expresses the meaning I've in mind, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
On Fri, 2008-01-11 at 12:29:40 -0500, Joey Hess wrote: Your continual closusre of this bug report Sorry, but the closure was not intentional, just what was on the Reply-To, and didn't see Frans reopen until later. Also notice you also replyed with the -done CCed. and refusal to listen to us is becoming very annoying. I don't think I'm refusing to listen, but it seems that to listen implies doing as you guys please. I just wanted a convincing argument. But this is getting non-constructive, and at some point I might just give up and not care at all. :/ regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
Guillem Jover wrote: Well then there's also the argument that there's no point in having it in the source control either, it could be inferred from the section. But those seem quite weak and specific ways to do so. Determining a file's type from its extension is weak and specific? Tell that to /var/lib/dpkg/info/*.p*. Tell that to everyone who has run dpkg -i *.deb and managed to not accidentially dpkg -i *.a (both ar files after all). Anyway, I don't think that'd be clean, and we might want to use that field for other package types in the future (translation debs, or debugging debs come to mind). You're designing for use cases that are not yet clear, and ignoring the current use case. I mentioned I'd implement it that way one year ago (or so) on #d-b, Um, all I got from your communication on this subject was that you would make it an official field, not that you would put it *in* the binary package. and no one seemed to oppose, and I requested comments on the patch implementing this again on #d-b few days before committing. That does not mean that decision could not be changed, but I don't see a good reason to do so, the current implementation seems cleaner anyway. If you cared so much about our opinion that you requested comments twice before, why are you continually ignoring our opinion now, and continually re-closing this bug report? -- see shy jo signature.asc Description: Digital signature
Processed: Re: Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
Processing commands for [EMAIL PROTECTED]: # Reopening as Joey closed it accidentally by using reply-to-all. reopen 452273 Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item Bug reopened, originator not changed. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
Guillem Jover wrote: There's 278 udebs in the current main Packages file. Each Package-Type field takes 19 bytes, so 5282 bytes of bloat. In comparison the Description field takes 49416 bytes. If you are really concerned about bloat, maybe you could trim those down instead. We are constantly trimming udeb descriptions. However, unlike this useless new field, udeb descriptions do have value -- they are displayed to the user. Your continual closusre of this bug report and refusal to listen to us is becoming very annoying. -- see shy jo signature.asc Description: Digital signature
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
On Friday 11 January 2008, Joey Hess wrote: Your continual closusre of this bug report [...] That's not correct. I'm afraid you closed it yourself the last time by using reply-to-all and thus including -done. Guillem only replied to your reply and probably also didn't notice -done was still in the address list. Anyway, I've reopened the BR again. Cheers, Frans signature.asc Description: This is a digitally signed message part.
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
reopen 452273 thanks On Friday 11 January 2008, you wrote: Given the rationale, I'm closing this bug. Joey, I don't think that that the Package-Type field ending up in the binary package can be qualified as bloat given that except the filename and the origin of the file, udeb can't be identified as such. I'm sorry, but I agree with Joey. There is absolutely no reason why we need the package type in the control file for udebs. They are already 100% identifyable by both section and extention. The way this was implemented basically just ignores the only current official user of the package type field, and is thus not policy compliant. From the PoV of the D-I team this is a real bug that needs to be fixed. Cheers, FJP
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
Package: dpkg-dev
Version: 1.14.9
Severity: normal
Tags: d-i
During a build of debian-installer-utils, I got the following warnings:
dh_gencontrol -i
dpkg-gencontrol: warning: deb package with udeb specific field
Installer-Menu-Item
dpkg-gencontrol: warning: deb package with udeb specific field
Installer-Menu-Item
dpkg-gencontrol: warning: deb package with udeb specific field
Installer-Menu-Item
However, debian-installer-utils does not contain _any_ deb packages,
only udebs. So the warning is clearly incorrect.
The cause may be that the header saying they are a udeb is in the
control file _after_ the header listing the menu item. The code should
probably allow for that.
Example of the control fields for one of the udebs:
Package: di-utils-shell
Architecture: all
Depends: ${misc:Depends}, di-utils (= 1.18)
XB-Installer-Menu-Item: 95000
Description: Execute a shell
XC-Package-Type: udeb
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-rc3 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages dpkg-dev depends on:
ii binutils2.18.1~cvs20071027-1 The GNU assembler, linker and bina
ii cpio2.9-6GNU cpio -- a program to manage ar
ii dpkg1.14.9 package maintenance system for Deb
ii make3.81-3 The GNU version of the make util
ii patch 2.5.9-4 Apply a diff file to an original
ii perl [perl5]5.8.8-12 Larry Wall's Practical Extraction
ii perl-modules5.8.8-12 Core Perl modules
Versions of packages dpkg-dev recommends:
ii bzip2 1.0.3-7high-quality block-sorting file co
ii gcc [c-compiler] 4:4.2.1-6 The GNU C compiler
ii gcc-4.1 [c-compiler] 4.1.2-17 The GNU C compiler
ii gcc-4.2 [c-compiler] 4.2.2-3The GNU C compiler
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
On Wednesday 21 November 2007, Frans Pop wrote: Should we start converting to use Package-Type? Note that doing so now would _add_ the Package-Type header in control files, which I do not think is desired. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
The actual problem seems to be that XC-Package-Type is not included in %f. Maybe because of the XC- prefix? From a debugging session: %f = ( 'Architecture' = 'all' 'Depends' = 'cdebconf-udeb, di-utils (= 1.18)' 'Description' = 'Execute a shell' 'Installer-Menu-Item' = 95000 'Maintainer' = 'Debian Install System Team [EMAIL PROTECTED]' 'Package' = 'di-utils-shell' 'Priority' = 'standard' 'Section' = 'debian-installer' 'Version' = 1.50 ) Note that almost all udebs currently have XC-Package-Type as header instead of Package-Type, so supporting that would be very much appreciated. Should we start converting to use Package-Type?
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
Hi, On Wed, 2007-11-21 at 17:10:39 +0100, Frans Pop wrote: The actual problem seems to be that XC-Package-Type is not included in %f. Maybe because of the XC- prefix? From a debugging session: %f = ( 'Architecture' = 'all' 'Depends' = 'cdebconf-udeb, di-utils (= 1.18)' 'Description' = 'Execute a shell' 'Installer-Menu-Item' = 95000 'Maintainer' = 'Debian Install System Team [EMAIL PROTECTED]' 'Package' = 'di-utils-shell' 'Priority' = 'standard' 'Section' = 'debian-installer' 'Version' = 1.50 ) Note that almost all udebs currently have XC-Package-Type as header instead of Package-Type, so supporting that would be very much appreciated. It's not included and has never been, because only the ones with B are. But now it's explicit given that dpkg-gencontrol supports the field. Package-Type should have been XB- from the beginning. That information is pertinent to the binary package and not to the changes file. Also this way dpkg-deb will be able to automatically select the correct extension, for example. So if there's no other argument I'll close the bug report tomorrow or so. Note that apart from the warning the current udebs should build as before. Should we start converting to use Package-Type? Sure. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452273: dpkg-gencontrol: incorrect warning deb package with udeb specific field Installer-Menu-Item
Guillem Jover wrote: It's not included and has never been, because only the ones with B are. But now it's explicit given that dpkg-gencontrol supports the field. Package-Type should have been XB- from the beginning. That information is pertinent to the binary package and not to the changes file. No, there is no reason to bloat udebs with this infrormation. This information is only used when building udebs. -- see shy jo signature.asc Description: Digital signature
