action #28815
closedcompile a list of packages that are from sle but not maintained there
Added by lnussel almost 7 years ago. Updated about 6 years ago.
100%
Description
some packages are marked as coming from SLE even though not all or none of it's source packages are actually maintained there. Need to compute a list and discuss with maintenance.
Updated by lnussel over 6 years ago
- Due date changed from 2018-02-09 to 2018-03-25
- Start date changed from 2018-01-22 to 2018-03-07
Updated by lnussel over 6 years ago
- Assignee set to jberry
Jimmy, could you help me with this please?
Basically we need a script that looks at all binary packages in Leap that come from SLE based source packages. List all source and binary packages that are not in any kiwi file in 000prodoct on SLE side (ie unwanted or unsorted).
Updated by jberry over 6 years ago
Rather than just source packages which may be in SLE and maintained there, but contain subpackages (binaries) that are not shipped need to look at binaries. Roughly translated:
for binary in binaries:
if binary.origin = SLE and binary in unwanted:
some_new_list.append(binary.name)
Where is the list to be placed?
Unsorted would appear to be a full package list? Ignore anything in 000product/unneeded.yml
or 000package-groups/groups.yml#UNWANTED
?
Updated by lnussel over 6 years ago
Sorry, I missed the question :-(
jberry wrote:
Rather than just source packages which may be in SLE and maintained there, but contain subpackages (binaries) that are not shipped need to look at binaries. Roughly translated:
for binary in binaries: if binary.origin = SLE and binary in unwanted: some_new_list.append(binary.name)
Where is the list to be placed?
Dashboard or even just the output of a script that we can give to maintenance.
Unsorted would appear to be a full package list? Ignore anything in
000product/unneeded.yml
or000package-groups/groups.yml#UNWANTED
?
I think that is the input, yes. Looking at the output works too though as none of the generated kiwi files would contain the binaries.
Updated by lnussel over 6 years ago
- Due date changed from 2018-03-25 to 2018-04-13
Updated by jberry over 6 years ago
- Status changed from New to Feedback
Updated by jberry over 6 years ago
Verified the above works by installing in container.
Updated by jberry over 6 years ago
You noted that debuginfo binaries should be removed. There are also -debug- named packages and -debugsource. Is there a list of everything that should be excluded and/or who should I contact to review from maintenance?
Updated by lnussel over 6 years ago
I think we have filters for *-debuginfo and *-debugsource in other tools also
The contact would be Andreas Stieger
Updated by lnussel over 6 years ago
- Due date changed from 2018-04-13 to 2018-04-25
Updated by jberry over 6 years ago
Excluded debuginfo and debugsource in https://github.com/openSUSE/openSUSE-release-tools/pull/1503
Updated by jberry over 6 years ago
- Assignee changed from jberry to AndreasStieger
- % Done changed from 0 to 100
Merged. Per lnussel comment, Andreas could you have a look?
# from openSUSE:Tools repo
zypper in openSUSE-release-tools
osrt-unmaintained openSUSE:Leap:15.0
Updated by jberry over 6 years ago
discovered and resolved issue which effects this tool in pr#1505
Updated by jberry over 6 years ago
Disregard above link as I ran without rebasing on latest master so it includes debug packages.
Updated by AndreasStieger over 6 years ago
From Leap 42.3 maintenance experience, we can disregard discrepancies in subpackages being included or excluded. As long as the source container is maintained in SLE in some way or another then we will do maintenance updates for it, and thus inherit the code fixes for Leap.
Updated by lnussel over 6 years ago
So are you fine with the provided information Andreas, ie can the task be closed?
Updated by lnussel over 6 years ago
- Status changed from Feedback to Closed
so information was handed over, closing as done
Updated by lnussel about 6 years ago
I think sle-module-development-tools-obs-ftp-POOL-*.kiwi spoiled the list. The module actually does not map to channel so I think the content there is also unmaintained.
Updated by lnussel almost 6 years ago
- Copied to action #47819: compile a list of packages that are from sle but not maintained there added