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

How to get the component for source packages?


while trying to implement moving packages between component, for example
from non-free to main, correctly I encountered a small problem:
how to get the component for source packages?

First the package will land in NEW. Here we already need to guess the
component for the source package (as NEW is a suite). Currently I use
main (contrib, non-free) if the upload also includes a binary for said
component (first component wins; the list is hardcoded[1]). Even when we
get this wrong, it is not too bad as it will only affect new and there's
no need to care too much about it, but it fails for source-only uploads.
We could use the Package-List field, but that is optional.

Now somebody will add the new overrides for main in addition to those
already present for the old non-free package.

After this the package needs to move from NEW to the target suite. Which
means we need to copy the source and any binary packages to the right
target suite and component. And here we get the same problem: what is
the right component for the source package? The component in new might
be wrong (see above), we cannot cheat and use the one from the overrides
as we have two of them, and we cannot guess them as we have the same
problems as above.

As far as I can tell, the current implementation uses the section from
the Files field in the .changes, but this is also optional (it contains
only a "-" if d/control only has Section and Priority fields in the
binary package stanzas).  I haven't yet tried what happens if this
information is not included.

An easy solution would be to require that there is only *one* override
for each (package, suite, type) tuple, ie. change the primary key of the
override table to no longer include the component.  This means the
package would first have to be removed from non-free before it can be
installed in main.  This change might also result in dak not noticing
when a source package (and no binaries) move between components and
continue to use the old component for it[2].  I don't think this would
be a problem in practice and it seems better than relying on
undocumented fields and/or guesswork.

Any thoughts about this?


[1] This could be avoided by checking if all binaries belong to the same
component and use that and/or introducing an ordering between components.
[2] As the component for source packages would always come from the
override table (except for NEW where we continue to guess it).

Reply to: