Bug 2770 - nice handling of url sources when getting new version
Summary: nice handling of url sources when getting new version
Status: RESOLVED FIXED
Alias: None
Product: Infrastructure
Classification: Unclassified
Component: BuildSystem (show other bugs)
Version: unspecified
Hardware: All Linux
Priority: Low enhancement
Target Milestone: ---
Assignee: Sysadmin Team
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-18 22:17 CEST by AL13N
Modified: 2014-05-08 18:06 CEST (History)
2 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description AL13N 2011-09-18 22:17:53 CEST
perhaps during submission sources could be checked against .asc or .sig files.

and actually, i donno if this is feasible or not, perhaps upload could be done during submission step as well? (sources who are url format). for big source files and upload step this could be helpful.
Comment 1 Nicolas Vigier 2011-09-18 22:22:06 CEST
what would be the use of this ?

CC: (none) => boklm

Comment 2 AL13N 2011-09-18 22:26:48 CEST
imo: if you have a huge source file and a slow upload internet, it could be beneficial to have the servers in datacenter fetching the missing files themselves.

in fact updating to a newer version, could maybe even delete the old and upload the new one in the submit step.

I'm not saying it's important, it isn't, but it could be nice.

Priority: Normal => Low

Comment 3 Nicolas Vigier 2011-09-18 22:27:56 CEST
I was talking about checking .asc or .sig files.
Comment 4 AL13N 2011-09-18 22:31:57 CEST
oh, doublechecking if the source is actually correct and rejecting submission if it is not.
Comment 5 Nicolas Vigier 2011-09-18 22:32:44 CEST
For download of files directly on the server, I was thinking about adding this as an option in mgarepo sync, with the new binrepo (to pass an URL instead of a file on stdin). But it seems I was too lazy and did not do it. And now I am no longer in sysadmin. But someone else can do it.
Comment 6 Nicolas Vigier 2011-09-18 22:35:21 CEST
(In reply to comment #4)
> oh, doublechecking if the source is actually correct and rejecting submission
> if it is not.

We already have the sha1 to check that the source is correct. And we cannot know which key to use to check the signature files.
Comment 7 AL13N 2011-09-19 02:40:29 CEST
hmm, you have a point there...
Comment 8 Marja Van Waes 2011-12-31 15:19:59 CET
pinging. because nothing happened to this report since more than 3 months ago, and it still has the status NEW


@ AL13N

Maybe I didn't read attentively enough, but is it correct that this report isn't about checking submission sources against .asc or .sig files any more?

If so, please adjust the summary of this bug to what it should be, or close it if there is no issue left to fix :)

CC: (none) => marja11

Comment 9 AL13N 2012-01-01 03:17:03 CET
(In reply to comment #6)
> (In reply to comment #4)
> > oh, doublechecking if the source is actually correct and rejecting submission
> > if it is not.
> 
> We already have the sha1 to check that the source is correct. And we cannot
> know which key to use to check the signature files.

they are correct between the link of packager and submission, but not from upstream. but otoh, packager needs to check this anyway, so that's sort only useful for a very tiny percentage...

changing it to what this is about now:

what would be really beneficial is a mgarepo command that works like this:

[]$ mgarepo getupstream 1.12.3

modifies spec file, gets newer sources and deletes old sources, makes everything ready for commit. perhaps this could indeed be a sync option, or just separate...

Summary: handling of .asc (or .sig) files (and perhaps url sources in general) => nice handling of url sources when getting new version

Comment 10 Nicolas Vigier 2012-01-01 16:47:03 CET
You can already modify the spec file for the new version, then run mgarepo sync -d to download the new files.
Comment 11 AL13N 2012-01-01 20:36:09 CET
ah, ok, then this is sufficient for me; closing issue as resolved (does it delete the old ones too?)

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Nicolas Vigier 2014-05-08 18:06:00 CEST

CC: boklm => (none)


Note You need to log in before you can comment on or make changes to this bug.