Hi Andreas and Ralf, On Mon, Jul 17, 2023 at 04:08:48PM +0200, Ralf Treinen wrote: > > Moving the usertag to the qa namespace sounds like a good idea. > > I agree
Thank you > Sounds like a good idea. However, I do not think that usertags support > a hierarchy of tags. So maybe different specific usertags with a common > prefix, like > > fileconflict-installation (error occurs when one tries to install two > packages togther) > fileconflict-upgrade (error occurs when upgrading, due to missing > breaks/replaces) > fileconflict-directory (error occuring due to /usr merge) Can either of you elaborate on the need to further classify the kind of conflict (file / directory / symlink / ...) or the kind of cause (installation / upgrade / ...)? Are you ok with explicitly excluding issues that only arise as a result of /usr-merge. These have a temporary cause and will vanish before too long. Due to the automatic bug filing that I hope to be doing, I need very precise tagging for them. Often times, it is initially not trivial to figure out whether a conflict only arises from installation or upgrades. Rather I propose to have a grab-bag tag for all of them. That allows us to move forward with less complexity and makes it easier to understand for everyone. Most of these issues result in an unpack error one way or another, but the symlink vs something else conflicts may result in unpack-dependent behaviour. I think we have consensus on using the debian-qa list, but I've seen file-overwrite and fileconflict-* as proposals with varying subclassification now. While we don't have a tag hierarchy on a technical level, Paul indicated that we may establish a hierarchy using processes. Using fileconflict makes it easy to establish a fileconflict-* subclassification later (by having the qa bot automatically add the super tag when it sees a sub tag). Is this convincing enough to move forward with the generic debian...@lists.debian.org usertag fileconflict rather than something more detailed? Is this also convincing enough to extend it to cover non-file conflicts or do you want a different tag for that? Should the tag also cover m-a:same file conflicts? I certainly won't object to doing a subclassification and I'm happy to add the subclass tags if doing so does not incur unreasonable implementation cost, but I don't want to participate in designing them nor updating existing tags. My need here is automatically ignoring detected issues that already are reported and the generic variant is sufficient for doing that. Helmut
