On Friday, May 10, 2019 2:17:15 AM CDT Adrian Schröter wrote:
In first place I would say these are all packages which actually got build, no? So the ones below /build/$project. Because beside the listing of source package containers also the project configuration (_meta and _config) has an influence what get built and what not.
Yes, it becomes a bit more difficult for maintenance_release projects since these projects are not supposed to get built, yes getting releases.
Could you explain a bit more what you plan to do with the information of "real packages" ? We could do that also in a chat later today ....
My first e-mail explains exactly what information is desired. Trying to filter the list to remove "packages" that are implementation details and not the thing actually being maintained. Such a distriction is useful for filtering lists presented in interface we use as well as not wasted queries on "packages" that are no relevant to tools since they cannot be maintained. There is no need to define this in some abstract sense on which we agree. Want a mechanism to filter maintenance update packages, multibuild sub packages and multi-spec sub packages. Either all the information needs to be in a listing API or the filtering done server side. As a side note, you can in-fact submit an update to Mesa-drivers. It will not have the result you want, but it is not prevented. We have had packages be submitted backwards, especally a few confusingly named python ones. In a summary interface one does not want nor desire to see that dozen maintenance update packages for every package bloating the list. One wants to see Mesa, not Mesa, Mesa.123, Mesa.124, Mesa.125, ... Regardless of implementation OBS side there should be a way to differentiate in a listing API call. -- Jimmy -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org