[packagers] Introduction

Dag Wieers dag at wieers.com
Mon Aug 15 02:46:57 CEST 2005


On Sun, 14 Aug 2005, Wil Cooley wrote:

> On Fri, 2005-08-12 at 03:19 +0200, Dag Wieers wrote:
> 
> > Would you be interested to maintain some of these packages or help out 
> > with RPMforge ? You seem to have the right skills :)
> 
> Thanks!  That was why I introduced myself and have been hanging around
> #rpmforge for the last few weeks :)

Hehe, we definitely need a wiki to allow people to add themselves (with 
contact info like IM and simple nickname :)

I'm definitely not relating emails with irc atm.


> I have a number of spec files that are my own and work for me, but could
> use other testing.  Should I just submit each as a patch (including init
> scripts, etc) here?

Well, it depends. (see below) If these are patches/spec-files for 
suplemental packages, not problem. If they interfere with core packages 
they might be a problem.


> (As an aside, considering how much patches are
> passed around via e-mail, Bugzilla, SF's patch utility, it's a wonder
> that none of the SCMs have a more tightly integrated patch-submission
> system, whereby untrusted users could submit patches for easy review for
> trusted users, who could then commit.)

I agree.


> Are there any particular changes in SpamAssassin 3.0.4 that make
> building or using it on EL3 difficult?  Any technical reason it hasn't
> been upgraded, particularly since it fixes a potential DoS?

We should have a policy to add comments about things like this. The main 
reason was it requires a core perl module newer than the one that comes 
with EL3 :(


> Have you guys worked out a system for monitoring packages for upstream
> updates, like slurping the daily Freshmeat releases RSS and comparing it
> to packages in a database?

I have written something like that once, but it could be improved (and 
written in python). I have been experimenting with python+sqlite and I was 
amazed of the speed. I am able to scan almost 40k packages in under 5 
seconds and put them in a sqlite database and then process the database 
and make stats in 2 seconds. (obviously this is done in RAM completely)

And I wrote a simple obsolete script with the rpm-python's version 
comparison, which automates what I have been doing manually for hours the 
last year. It's not doing everything yet though... buildlog maintenance 
is largely missing. But if it's running correctly I could get rid of about 
15k packages by running it. Obviously I should have automated even more in 
the past. Especially if you look at the simplicity of the scripts...

I'd like to make conventions about file formats and builder information 
that allow us to merge these files and do centralized processing of this 
information. Flat files (since that syncs much better than sqlite 
databases)


> There are currently a number of packages maintained by individuals, like
> Simon Matter's Cyrus IMAP or Simon Mudd's Postfix, that are fairly
> important to me.  I currently usually build these myself or use their
> binaries.  Plus, there are a handful of source packages that ship with
> an adequate spec file in the source or that are part of Fedora Extras
> but not built for EL[234]; has there been any thoughts of how and if to
> integrate some of these?

If you need these in a production environment, it's best you become a 
maintainer of them. This means you make final decisions of the packaging 
and do test builds on your own system to verify they work.

The main problem with things like postfix is that they may not interfere 
with core packages and we may have to make a seperate repository for 
those. (Or rename them and add conflict tags so people understand that 
they deviate from the normal packages)

We have to think careful about this, this is a sensitive issue for some 
people.

Kind regards,
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]



More information about the packagers mailing list