[repo-coord] Packaging Process - PLEASE READ

Dag Wieers dag at wieers.com
Fri May 28 01:07:19 CEST 2004


On Thu, 27 May 2004, Rudolf Kastl wrote:

> Am Do, den 27.05.2004 schrieb Bent Terp um 9:07:
> > On Fri, 2004-05-21 at 04:47, Rudolf Kastl wrote: 
> > > 1. we need to specify checks for the source code. Means checking if the
> > > source is alright or no in terms of malicously changed.
> > 
> > GPG sigs? MD5 checks? What else should I consider?
> 
> not every source download provides a gpg signed or md5 checked source.
> we need a general solution for that. if not please dont replace system
> internals or anything else that is properly checked... cause you never
> know... remember when the bitchx site was hacked? remember when
> themes.org was hacked? ....

I'd like the buildsystem to add md5 checksums to the SPEC-file so others 
can verify the checksum at any point in time. Whenever a mismatch is 
encountered the buildsystem should report that to a public 
archived mailinglist. The more people use the same buildsystem (for 
multiple platforms), the better the results and the safer we will feel.
 

> > > 1. perl and sed should be avoided
> > 
> > Disagree. Again, life is short and a perl one-liner is much more
> > resilient than a patch - e.g. " find . -name \*.h | xargs -i{} perl -pi
> > -e 's[/usr/local][/usr]' {} " is more likely to survive a
> > version-update. 
> 
> if you use perl or sed you read all files that affected each time... you
> can do that and just diff a patch... its one command... send it upstream
> and it can be fixed... everything else is butchering with alot bork
> potential. especially if just blindly done on a new release.

I disagree. A perl-oneliner should be carefully crafted by someone who 
knows what he's doing. You gain simplicity, better understanding of what 
smt. does, easier to manage/improve and you gain a lot of time not 
spending on patching for each release.

And with a few fixes to the buildsystem, one can easily verify if a 
perl-oneliner is still being useful or already been applied upstream.

PS perl oneliners are also easier for upstream, especially when the 
upstream version has been changed a lot.

PS2 I'm not saying everything should be done with perl-oneliners. But if 
a simple perl oneliner can replace a 20 line patch, I'd go for a perl 
oneliner.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]



More information about the repo-coord mailing list