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]
