propose Generate.SoureceX.sh script

msuchy commented

2024-03-30 16:35:49 +00:00

Member

This will recommend that tarball that does not have URL must include
script that will generate the tarball.

This will allow automatic check of the content of the tarball.
And it will provide a record how the tarball was generated.

This will recommend that tarball that does not have URL must include script that will generate the tarball. This will allow automatic check of the content of the tarball. And it will provide a record how the tarball was generated.

tibbs commented

2024-04-04 16:40:09 +00:00

Owner

My personal observations (that I entered yesterday and yet never submitted):

I agree with this conceptually; we should at least provide suggestions for how this should be done, with an eye towards enabling more automation.

Following this shouldn't be any sort of requirement at this point. maybe later. The only requirement should be that if a script has the prescribed name, then it MUST follow the format

I don't understand why you would require something to substitute in %{version} and such when those could be passed in the environment or as positional arguments. Is there some kind of security consideration here that I'm not understanding?

What is the state of the various bits of automation which would use this? Is there a proposal elsewhere to set up automated checks based on this? Is there a ticket or PR against fedpkg or some adjacent tool to handle passing the information to the script to automate the downloads?

My personal observations (that I entered yesterday and yet never submitted): I agree with this conceptually; we should at least provide suggestions for how this should be done, with an eye towards enabling more automation. Following this shouldn't be any sort of requirement at this point. maybe later. The only requirement should be that if a script has the prescribed name, then it MUST follow the format I don't understand why you would require something to substitute in `%{version}` and such when those could be passed in the environment or as positional arguments. Is there some kind of security consideration here that I'm not understanding? What is the state of the various bits of automation which would use this? Is there a proposal elsewhere to set up automated checks based on this? Is there a ticket or PR against fedpkg or some adjacent tool to handle passing the information to the script to automate the downloads?

msuchy commented

2024-04-04 16:59:28 +00:00

Author

Member

I don't understand why you would require something to substitute in %{version} and such when those could be passed in the environment or as positional arguments. Is there some kind of security consideration here that I'm not understanding?

The script will live outside of the spec file. So macros expansion will not work. Therefore I suggested to use only these ones. But yes, passing them as positional arguments is option too. And likely better option :)

What is the state of the various bits of automation which would use this? Is there a proposal elsewhere to set up automated checks based on this? Is there a ticket or PR against fedpkg or some adjacent tool to handle passing the information to the script to automate the downloads?

Packit will find this beneficial. Packit can create new version of package when there is upstream release, but only if SOURCE is URL. When it is file there's nothing to do.

And I guess QA can later use it too, to determine if there are potential differences.

> I don't understand why you would require something to substitute in `%{version}` and such when those could be passed in the environment or as positional arguments. Is there some kind of security consideration here that I'm not understanding? The script will live outside of the spec file. So macros expansion will not work. Therefore I suggested to use only these ones. But yes, passing them as positional arguments is option too. And likely better option :) > What is the state of the various bits of automation which would use this? Is there a proposal elsewhere to set up automated checks based on this? Is there a ticket or PR against fedpkg or some adjacent tool to handle passing the information to the script to automate the downloads? Packit will find this beneficial. Packit can create new version of package when there is upstream release, but only if SOURCE is URL. When it is file there's nothing to do. And I guess QA can later use it too, to determine if there are potential differences.

tibbs commented

2024-04-18 17:19:57 +00:00

Owner

Metadata Update from @tibbs:

Pull-request tagged with: meeting

**Metadata Update from @tibbs**: - Pull-request tagged with: meeting

decathorpe commented

2024-12-02 23:44:07 +00:00

Owner

Note that a similar RFC in the past has been stalled in bikeshedding:
https://pagure.io/packaging-committee/issue/1132

I offered to implement support for something like this in spectool, but since it couldn't be agreed on what should be done, I didn't implement it. (maybe I just should do something ...)

Note that a similar RFC in the past has been stalled in bikeshedding: https://pagure.io/packaging-committee/issue/1132 I offered to implement support for something like this in spectool, but since it couldn't be agreed on what should be done, I didn't implement it. (*maybe I just should do __something__ ...*)

ngompa commented

2024-12-03 11:57:38 +00:00

Owner

I keep thinking about implementing a harness to run OBS source services too... We have a few of them packaged, we just don't provide a mechanism to run them right now.

This pull request is broken due to missing fork information.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin generate.sourceX.sh:generate.sourceX.sh

git switch generate.sourceX.sh

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main

git merge --no-ff generate.sourceX.sh

git switch generate.sourceX.sh

git rebase main

git switch main

git merge --ff-only generate.sourceX.sh

git switch generate.sourceX.sh

git rebase main

git switch main

git merge --no-ff generate.sourceX.sh

git switch main

git merge --squash generate.sourceX.sh

git switch main

git merge --ff-only generate.sourceX.sh

git switch main

git merge generate.sourceX.sh

git push origin main

Rows
Columns

propose Generate.SoureceX.sh script #1351

Checkout

Merge