[Frugalware-devel] questions about syncpkgd2

[Gabriel C]

VMiklos wrote:
> hi,

Hi,


> 
> probably you know, there is an old idea about rewriting syncpkgd,
> basically with the following goals:
> 
> - support more than one buildserver for one arch
> 
> - make it more efficent: create a central server that acts like a
>   mailbox: receives requests to build (probably from a push hook) and
>   gives the syncpkg client daemons packages if they request one. this
>   way the response time of the client daemons would be much less, as
>   currently _they_ try to determine what packages needs building, which
>   is an expensive task and thus they do it only one in 2 hours. also
>   then they try to build all the packages, instead of one, then asking
>   from the server what to do again
> 
> one question i'm not sure about: how to determine if we want to build a
> package or not?
> 
> the problem is the following: currently we upload packages manually, and
> syncd uploads them automatically, too. this causes several problems, for
> example syncd may overwrite your build, etc (okay they are not _that_
> big problems, the worse can happen is that a user has do -Syu twice,
> because first pacman removes the corrupted packages, and second time it
> downloads the new ones, but it's quite annoying)
> 
> we have to choose:
> 
> 1) still allow this feature (uploading packages manually and
> automatically, too) or
> 
> + no big change, does not violate freedom
> - when will we build a pkg? if no upload with in ie 2 hours? that will
>   slow down syncd again

Really what do you mean by *slow down* ?! 

> 
> 2) no longer allow devs to upload packages manually
> 
> + this way we can be sure about the packages are built in a clean
>   chroot, no implicit tricks, etc
> - if syncd is broken, no package upload is possible
> - this new syncd is less tested than the old, it's possible that for the
>   first time we'll have problems with it

  - if syncd is acting up ( deleting packages or whatever else ) we are screwed
  - in 'long-term' no one will even *try* to build any package local resulting in :
	-- s/1.2/1.2.1/ && push out
		which means again :
			-- broken and not tested packages _at_ all

( I'm sure there is more but I'm on the way to bed now :P )

> 
> so, what do you think about this? i think in long-term it would be good
> to choose 2), that would ensure a higher package quality
> 

Only 2 is not a good idea , giving only some build tools ( scripts etc ) the power to upload fpm's / packages
is wrong .. ( of course IMO ) 

And I don't agree at all about the 'higher package quality' packages we already check for 'chroot builds'
on upload and that is good as is.

> in short-term, maybe it would be good to choose 1), but then we need
> this ugly "build the pkg if no fpm uploaded in x time" hack, and we
> should decide such an interval

Why ugly ? and why we need run the daemons all xx minutes or all some hours ?

Run 'twice' a day and is fine for stable and current 


> 
> thanks,
> - VMiklos


crazy