I don't want to add yet more content-type-specific tables and calls if we can help it. The archiveinfo table is already nicely generic.

I have a patch in progress to support more generic archive imports in koji. I think this is probably how we will handle deb packages.

https://github.com/mikem23/koji-playground/commits/cg-generic

(the linked will should land fairly soon. there are a couple things mikeb and I need to sort out first)

@mikem, I don't mind re-writing this to use archiveinfo table but given that I'm planning on adding the tasks needed for DEB building wouldn't it make it more maintainable to have a separate table for the DEB package?

Am I correct to say that you prefer something like:
a) Use of archiveinfo table for the basic information
b) Use a deb_archives table (similar to maven_archives) for anything DEB specific (like version, release etc)?
c) Use of the archiveinfo web view

I'm happy to do those changes. I'll have a look at your cg-generic branch to see if I can rebase it on this, let me know if you agree on those.

@ctria Any progress on this?

Waiting on feedback on my comment above. The cg-generic branch when I last checked it wasn't merging cleanly on current master so I'm waiting for an update when the work that @mikem mentioned is merged.

I'm working on updates the the cg generic branch now, sorry for the delay. Should have something later this week.

@mikem Any progress on the cg generic stuff?

@mikem can you confirm if all the needed commits for cg generic are merged? Can I proceed with a rewrite based on it?

It is also not clear to me how building the packages will work with that approach. Wouldn't that require separate tables for DEB anyway? what's your thoughts on that?

@mikem can you confirm if all the needed commits for cg generic are merged? Can I proceed with a rewrite based on it?

It is also not clear to me how building the packages will work with that approach. Wouldn't that require separate tables for DEB anyway? what's your thoughts on that?

They are not yet merged. Planning to merge them later this week.

I'm not sure which tables you're thinking of. Approach would be: perform build, collecting metadata, and import at the end.

btw, the cg-generic work was merged

https://pagure.io/koji/pull-request/161

The cg generic changes obsolete lots of this, though they don't offer any way to query the debian packages themselves (e.g. getDEBDeps, listDEBFiles, getDEBFile, getDEBHeaders).

I think any future work on this should probably be a new PR, so closing this one out.