Mirrored package identification

[jacksga]

Summary of the changes

• Lets BaGetter store wether a package was mirrored and if so, from where
• Can be used as base for different cleanup routines

Addresses #187

[jacksga]

Hey @Regenhardt and @FroggieFrog,
is there a chance of getting your thoughts on this and if this is something you'd support in this way as a foundation for easier cleanup routines etc in the future?
Thanks in advance

[jacksga]

Hey, could you please provide me with some form of reaction or feedback regarding this?
@Regenhardt

[Regenhardt]

Hi yes sorry, I definitely like this, just want to combine it with something else that also needs to modify the DB schema.

[seriouz]

@Regenhardt Do you still have further plans on this?

[hoerup]

@Regenhardt could you please take another look at this one ?

[jacksga]

Hey @Regenhardt is there any chance we could get this wrapped up and done this year as a christmas present for everyone trying to identify mirrored packages for cleanup?

[Regenhardt]

Would actually prefer sometihng like UpstreamSource instead of MirroredFrom, not sure why though so I'm open for arguments here.

[Regenhardt]

Maybe we can indeed get this wrappped up for christmas :)

Also rebase (or merge main) please.

[jacksga]

Would actually prefer sometihng like UpstreamSource instead of MirroredFrom, not sure why though so I'm open for arguments here.

For me upstream in a general software development perspective is more missleading than mirror, therefore I opted for MirroredFrom. Would also be up for a mix (MirrorSource) but in perspective of getting it done before christmas I'd choose whatever your last word is :D

When you decided on the name for the property I will rebase, change the name, fix the domain and usings and create new migrations.

[Regenhardt]

Happy new year!
You won't guess what I got for christmas: A fried boot drive, yay!

Anyway, how about SourceUri? I want to avoid spreading the "mirror" description any further as BaGetter technically does not mirror a source, which has already lead to confusion before, as packages are cached on pull but not actively mirrored. I do understand upstream possibly being confused for an original code repository though.

[jacksga]

Happy new year to you too, I'm sorry to hear that, hope you haven't lost anything important except from time and nerves.

When reading your comment I figured well yeah, they are cached, so why not CachedFrom, CacheUri or CacheSource, those seem the most fitting. Would opt to CachedFrom as well as I'd rename the parameters etc from mirror to cache.

If you don't like the idea I will just use SourceUri.

Being back from vacation I do now have the time to finish everything after we sorted the naming thing.

[Regenhardt]

Welcome back, hope you had a nice vacation. Thanks, yes it was mostly the time, I fortunately had mostly just windows itself on there.

I think CachedFrom is great, it conveys intent and has less other meanings it could be confused with, let's go with that. Don't rename the existing object from the appsettings though, to avoid the breaking change.

[Regenhardt]

Ok this should be the last time I send this back, thanks a lot for staying with me on this.

[hoerup]

@jacksga great work and I appreciate your patience on this

Could you implement @Regenhardt's suggestions so this finally can be merged ?

[Regenhardt]

Thanks a lot for the contribution, I'm still testing and will not immediately make a new release to check if we can include more db changes in a single release.