[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