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

(low priority) udeb naming



[ Please preserve CC's while the lists are down and feel free to add
more. ]

On IRC we were discussing why there is the requirement that udebs have
names different from debs in the archive. I looked back at my mail
archives from when this was set up, and could find only one good reason:

On 13 Dec 2000 I wrote:
> James Troup wrote:
> > You can't have a .udeb with the same name as a .deb; this is enforced
> > by katie (i.e. the package will be REJECTed) at JoeyH's specific
> > request.
> BTW my reasoning behind that is it could get confusing if someone
> manages to install a udeb onto a full debian system, and then runs into
> bugs and we don't realize they are due to the udeb, etc.

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

Weighing on the other side of this are the problems that we now know 
having separate names cause:

 - Calling things di-foo.udeb, foo-udeb.udeb, foo-di.udeb, is inconsistent
   and ugly. And what if we have a main-menu.udeb now, but later decide we
   want a main-menu.deb too (this is only partly hypothetical, I need
   something like it for base-config).
 - We cannot have a libc6.udeb, so udebs cannot use dpkg-shlibdeps to
   generate their dependencies, except that most of them still do and we
   get broken deps in the d-i archive. This has made it hard to make d-i
   handle library udebs right, I won't go into the whole mess.

I think that this naming requirement was a bad idea, and we should
open up the archive for debs and udebs with different names.

Note that this doesn't entirely solve the library udeb problem, as a
udeb that depend on libc6 (>= foo) still violates udeb policy (by having
a versioned dependency). But it's a step in the right direction.

-- 
see shy jo

Attachment: signature.asc
Description: Digital signature


Reply to: