#1743 basic zchunk support for dist-repo
Merged by tkopecek. Opened by tkopecek.
tkopecek/koji issue1198  into  master

Download 1743.patch

Fixes: https://pagure.io/koji/issue/1198

Metadata Update from @tkopecek:
- Pull-request tagged with: testing-ready

Should be default=None for consistency?

Should be default=None for consistency?

yep, updated

rebased onto 3a1a777ecd51fc4750a4bdee8a5396a44bd31334

@tkopecek How difficult would it be to make this a per dist-repo tag feature instead of a per-builder feature?

@ngompa It would be easy. What I'm struggling with, is how zdict data would appear on builder. They could be 'always there' installed via rpm (then we just need path or filename in tag's extra), or they need to be downloaded from somewhere (and url in extras), which seems to me costly.

or it is a file? and I'm nore sure if ../* could bring security issues here

@tkopecek They're significant enough that I think it's most likely they'll always be available via RPM. But it could be fetched, and maybe kojid could cache them somewhere in that case?

rebased onto e23f1adf76f621fafc2c5033e907ff21d2484740

Metadata Update from @jcupova:
- Pull-request tagged with: testing-done

@julian8628 What exactly do you mean? There is a check on existence of directory few lines later.

@tkopecek I think supporting either local files (installed on builder) or fetching remotely should be supported. But I'm comfortable with this being per-tag and also being local-only if you feel that's the way to go.

I know Koji instances exist that build for multiple distributions (heck, Fedora's is one!) and it's totally conceivable to have different zdicts for each build target.

@julian8628 What exactly do you mean? There is a check on existence of directory few lines later.

Ah, I meant the GenericError is not accurate, if zck_dict_dir exists but is a file.

And I'm not sure it will modify or expose some thing under zck_dict_dir (I don't know very well about this mechanism. Sorry for that stupid question :-( )

rebased onto 98c765d01c1ba804998b0582414ca9c9ff4fd92f

:thumbsup:

Would this throw an error if the directory is a symlink? We probably want this to work if it is a symlink.

Commit 6ecffb8f fixes this pull-request

Pull-Request has been merged by tkopecek

@ngompa It works correctly for symlinks.

Metadata