Bug 713802 – New QA policy suggestion: Ban live-only packages (where snapshot is available)

• Product: Quality Assurance
• Status: CONFIRMED ---

[Description Joonas Niilola 2020-03-21 14:47:08 UTC]

Hey, 

first of all I couldn't find any official info on how to submit QA policy suggestions. 

Then onto mine: 

I strongly feel like any non-keyworded packages should be banned. Clarification: I mean packages that only have -9999 ebuilds available in ::gentoo, and no ebuilds with KEYWORDs (where upstream has Git-like VCS). 

Rationale being the same as why -9999 packages can't have KEYWORDS: They are unpredictable and potentially insecure. Unpredictability could mean upstream repo being broken at any given time placing users in an awkward situation, where they are able to build some packages while not the others. Upstream repo can also be force-pushed over. I feel like packages offered in ::gentoo shouldn't have these issues, and there should be at least one safe release available to users. 

With Git-like VCS's becoming popular, it is super easy to create an unchanged snapshot based on a commit. 

Then onto another problem I've noticed: 9999 ebuilds aren't updated regularily. I know some people keep latest release and -9999's in sync, and this is totally fine, but when proxy-maintaining many of these -9999 ebuilds they get ignored. Thus they are broken, like in the example below:  

I looked at app-leechcraft/* and counted 72 packages where only 3 had KEYWORDS. Rest are pure -9999 only. When trying to emerge leechcraft-meta I was faced with unsatisfied deps (I guess removing these deps won't be caught by CI tool since leechcraft packages are masked by missing keyword?) and I couldn't continue. These ebuilds have last been touched in 2017, so it's no wonder they are outdated and broken. With this QA policy ::gentoo would've been saved from carrying dead ebuilds around for this long, and this dead weight being synced to every user's machines.

Leechcraft is being developed in Github and regardless of the outcome for this policy I will contact the maintainer next. 

Repoman and pkgcheck can probably easily force/track this policy too.

Truthfully I thought a policy like this existed already.

[Comment 1 Thomas Deutschmann (RETIRED) 2020-03-21 15:02:40 UTC]

And how about new packages still in developing and not yet ready to get tagged?

Some developers are actually developing on Gentoo and live ebuild allows you to get all the benefits from packages itself combined with latest code. For example when I worked on genkernel-4 I used live ebuild a lot. Now you will probably answer that genkernel wouldn't be affected because it has keyworded ebuilds but look how even pkgcore started in Gentoo (as live-ebuild only package)...

I also get your point. I can't say anything about app-leechcraft. Let's hope they have a good reason or couldn't think of a better solution for _now_.

My point is: We shouldn't need a new policy for that. It should be common sense that a live-ebuild only package doesn't make much sense the long term. However, if we have a policy, even short term live-ebuild only packages would be banned or violate policy. 

Any policy which will have know violators/exception is a bad policy and shouldn't exist from my POV.

[Comment 2 Joonas Niilola 2020-03-21 15:14:08 UTC]

(In reply to Thomas Deutschmann from comment #1)
> And how about new packages still in developing and not yet ready to get
> tagged?
> 

I don't see any problem making an ebuild with -0_pre<date> format every now and then. Should reach more users than a pure -9999 ebuild anyway. Check rlottie, upstream hasn't yet made a release, it has commits in Github ~daily and many consumers in Gentoo already. It's keyworded for multiple arches already and stabilized on couple. 

> 
> My point is: We shouldn't need a new policy for that. It should be common
> sense that a live-ebuild only package doesn't make much sense the long term.
> However, if we have a policy, even short term live-ebuild only packages
> would be banned or violate policy. 
> 

Yes, maybe "ban" is a bit harsh word. Of course they are given time to find and make a snapshot of a working commit. I felt like this is common sense as well, b ut you can't force action for a better change without having strict policies about them.

[Comment 3 Joonas Niilola 2020-11-02 14:58:29 UTC]

Created attachment 669767 [details]
9999_packages_only.txt

Hey, 

a slight ping. I'd like the QA team to make this an official policy. Since cleaning leechcraft, we have 43 -9999-only packages left in the tree. I've gone through all of them, and here's a link to the detailed list I gathered from them: 
  https://dev.gentoo.org/~juippis/tmp/9999_packages_only.txt

Because the list is too large to be pasted in the bugzilla, here's a summary. Out of 43 ebuilds, 

 - 2 are hosted in places that can't generate tarballs from commits - you can still utilize git tool and host a tarball in your own devspace. (5 %)

 - 3 are in maintainer-needed. (7 %)

 - 4 are maintained by candrews. (9 %)

 - 12 are still at EAPI-5. (28 %)

 - 17 are maintained directly or via projects by zero_chaos. (40 %)

 - 19 are currently unbuildable. (44 %)

 - 29 are hosted in Github. (67 % )

If the QA decides to make "no live-ebuilds only" policy true, I'll be filing bugs to each of these packages offering to help get them keyworded properly. Regardless, I'll be masking some of the dead packages listed above soon, and report bugs for broken ones that have hope to being keyworded.

[Comment 4 Joonas Niilola 2020-11-02 15:15:01 UTC]

And here's the final list and my next steps regardless of outcome for this bug:
Last-rites:                                                                                         
 net-analyzer/nagios-plugins-flameeyes                                                              
 net-misc/lcr                                                                                       
 net-misc/srf-ip-conn-srv                                                                           
 media-plugins/xbmc-addon-xvdr                                                                      
 app-i18n/kde-l10n-scripts                                                                          
 net-wireless/dump978                                                                               
 net-wireless/openggsn                                                                              
 net-wireless/osmocom-bb                                                                            
 net-wireless/openbsc                                                                               
 net-wireless/osmobts                                                                               
 net-libs/libosmo-netif                                                                             
 net-libs/libosmo-abis                                                                              
 app-emulation/rex-client                                                                           
                                                                                                    
Open bugs:                                                                                          
 app-doc/votca-csg-manual                                                                           
 app-misc/no-more-secrets                                                                           
 games-engines/exult                                                                                
 media-plugins/kodi-screensaver-crystalmorph                                                        
 media-plugins/kodi-visualization-nastyfft                                                          
 media-plugins/kodi-screensaver-rsxs                                                                
 net-wireless/qradiolink                                                                            
 net-libs/liba53                                                                                    
 net-im/psimedia                                                                                    
 app-emulation/qt-virt-manager                                                                      
 app-accessibility/simon  

Last-rites for packages that have dead upstream, and/or gentoo bugs open for a ~year without fix. Open bugs for packages that have active upstream and build issues can be easily fixed.

[Comment 5 Alessandro Barbieri 2021-03-13 02:49:32 UTC]

I've opened an issue in guru some time ago https://github.com/gentoo/guru/issues/32
For me 9999 are only double work to do: if you make a change in a package, you have to change the 9999 too