Re: (low priority) udeb naming
Joey Hess <joey@kitenet.net> writes:
> [ 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.
same
> 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.
But pretty much all udebs have versioned depends or should have them
for correctness. The few bytes wasted on the versioned depends don't
realy matter and are far outweight by the daily build process (apt and
dpkg specifically) actually checking the versioned depends.
It might not be policy to have a versioned depend but the current
implementation of d-i (run-time, not build-time) just ignores it. If
we see that we actually get version scews d-i can be made to generate
proper error for version scews later.
I think we should change udeb policy to allow for versioned depends
but note that the run-time will not (yet) enforce them.
MfG
Goswin
Reply to: