On Sun, Nov 23, 2003 at 05:43:19PM -0500, Joey Hess wrote: > But there are obviously other ways to guard against that if it is a > problem. For example, udebs could depend on broken-system, and then dpkg > would be pretty clear about what happens if you install them. :-)
While I could live with it, having every udeb depend on something inexistant just to keep it away from real systems is a bit dirty, IMHO. > - Calling things di-foo.udeb, foo-udeb.udeb, foo-di.udeb, is inconsistent > and ugly. (...) > - We cannot have a libc6.udeb (...) True. > I think that this naming requirement was a bad idea, and we should > open up the archive for debs and udebs with different names. I only partially agree. Having a udeb and a deb with the same name poses some problems. How will the BTS and other things which rely on the package name as unique identifier continue to work properly ? I don't think debian-installer can be considered as having a fully separated package namespace. I also think being able to install udebs on a real system could be a feature sometimes (if you really know what you are doing, obviously.) The clean way, IMHO, would be to only allow (and probably recommand) a udeb and a deb to have the same name when the udeb is the fat-free equivalent for the real package. After all, they're more or less two flavours of the same package. This could be tested automatically by allowing only name collisions within the same the same source package. -- Jeremie Koenig <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
