Ticket #353 (closed provenpackager request: fixed)

Opened 4 years ago

Last modified 4 years ago

provenpackager request for walters

Reported by: walters Owned by: kevin
Priority: major Keywords: meeting
Cc: Blocked By:
Blocking:

Description

Hi,

I'd like to be a provenpackager, mainly since I want to add #VCS keys and it's quite annoying to have to manually request an ACL in 3 different branches in pkgdb just for this.

Also it's likely I will touch most of the desktop-related packages at some point.

Change History

comment:1 Changed 4 years ago by pjones

+1

comment:2 Changed 4 years ago by skvidal

I'm inclined to +1. Walters works on projects which end up being all over the place packaging-wise.

He's not terribly likely to tromp over existing maintainers.

comment:3 Changed 4 years ago by bpepple

+1 (from former FESCo member)

comment:4 Changed 4 years ago by kevin

  • Type changed from task to provenpackager request
  • Keywords meeting added
  • Owner set to kevin
  • Status changed from new to assigned

Mailed sponsors list for feedback. Added meeting keyword to add to the next meeting agenda.

comment:5 Changed 4 years ago by kkofler

-1, invalid rationale

Global changes such as adding #VCS "keys" (more like magic comments, I guess, seeing how they start with a '#') only make sense if there's a guideline that they should be there. That's something for FPC to decide, not some random provenpackager. I think magic (machine-parsable) comments are a misfeature we shouldn't get into. If we consider VCS keys to be useful, RPM needs to understand them, if not, then why would we want to allow somebody to add them to all packages?

comment:6 Changed 4 years ago by jkeating

I'm going out on a limb and assuming that Walters is only planning on adding the comment to a few packages, not the entire distribution, and as such I don't see a problem with it. Neither do I see a problem with him being able to commit to desktop packages, as well as others as he has offered programming help before.

So +1 from me.

comment:7 Changed 4 years ago by walters

Hi, yes that's correct, I don't plan to commit to all packages. Basically my current goal is packages within my "sphere" which is largely stuff in @desktop - @base.

Also Kevin specifically: I have proposed it as a standard: https://fedoraproject.org/wiki/User:Walters/Packaging_VCS_key_proposal I pinged spot but didn't actually get it added to their queue yet, I'll look at that. Note I also patched RPM so it doesn't have to be a comment long term.

If it *is* accepted though, it's on my TODO list to write a script to automate adding them, where the package owner would confirm by some means "yes this is the right VCS URL". Being provenpackager would assist with that.

comment:8 Changed 4 years ago by cwickert

It's not that I mind you being a proven package Colin, but I cannot follow your rationale:

comment:9 Changed 4 years ago by walters

Hi Christoph, thanks for your comments.

  • That's true, however I would like to get some real-world testing of the proposal, and a good way to do this is by applying my scripts to a small but realistic set of packages. If the proposal gets changed later, I'm fully willing to update any packages I've changed.
  • It only exists if the *current* version is from a VCS snapshot, whereas I want the data to always be there, so that we can e.g. later perform correspondence checking between the source tarballs and the VCS, and so my scripts like "fedpkg-vcs pull-retarget HEAD" can automatically create a VCS snapshot that follows the guidelines.

comment:10 Changed 4 years ago by kkofler

The problem is that just because upstream uses a VCS doesn't mean a checkout is a valid tarball. For example, if you try doing that on any package from KDE SVN (other than the core KDE modules for which translations are in the kde-l10n langpacks), you'll end up with a package without translations, or with a build error on the %find_lang step (unless you want to duplicate the functionality of KDE's create_tarball.rb script). Another issue is with autotools-using packages, where sometimes generated files are included in tarballs, but not in the VCS. And then there's the completely arcane stuff like TIGCC where my tarball creation script copies stuff from 2 separate CVS repos and one directory which is not in CVS into a directory tree which doesn't match the one in CVS, building straight from CVS is outright impossible; there may be other projects doing something like that.

comment:11 Changed 4 years ago by kkofler

Oh, there are also now apps (e.g. Amarok, Konversation) where the code is in Gitorious git whereas the translations are in KDE SVN.

And no, translations in KDE SVN are not organized in per-app directories, the organization is language/module/application.po, e.g. de/extragear-multimedia/amarok.po, so they have to be collected by create_tarball.rb or a similar script. The create_tarball.rb script also adds a few lines to the toplevel CMakeLists.txt to build the translations.

comment:12 Changed 4 years ago by walters

Hi Kevin,

I agree those are issues to be tackled, and in fact not all projects even use revision control, sadly. However, I suggest these are issues to be discussed in the FPC, not in this provenpackager request.

comment:13 Changed 4 years ago by toshio

Yeah -- I've added a Discussion section to the bottom of the proposal page: https://fedoraproject.org/wiki/User:Walters/Packaging_VCS_key_proposal

Please add concerns directed at the policy there.

cwickert added the note that this isn't a packaging guideline yet and that's probably a sufficient note for this ticket.

comment:14 Changed 4 years ago by kevin

  • Resolution set to fixed
  • Status changed from assigned to closed

This request was approved. Added to group. Congrats.

Note: See TracTickets for help on using tickets.