[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

dep checker script (was: Re: Log from todays (20080130) EPEL SIG Meeting)



On 30.01.2008 23:07, Michael Schwendt wrote:
> On Wed, 30 Jan 2008 21:23:48 +0100, Thorsten Leemhuis wrote:
> 
>> 00:09:26 <       knurd> | so, how to move on? ask mschwendt to install is? nirik, or do you want to handle that? you likely have the needed permissions as well
>> 00:09:42            --> | mdomsch (Matt_Domsch)  has joined #fedora-meeting
>> 00:10:11 <      smooge> | mdomsch, has permission to. he can do anything :)
>> 00:10:17 <       nirik> | sure, I can ask him if we can just run it on the buildsys box, or what.
>> 00:10:27 <       knurd> | nirik, k, thx
>> 00:23:51 <       nirik> | knurd: I mailed mschewnt asking about setting his script up on the buildsys box
> 
> So, here are some public comments on that.

thx for your detailed mail Michael. It helps a lot!

> Didn't know this was a topic in the meeting once more.

Well, a solution still hasn't be found and we need a dep checking
script. We could reenable the old one, but it doesn't mail the list, and
that's needed as some fellow packagers ignore ^w miss the mails they get
directly.

> [...] 
> The recently published repoclosure tarball is easier to modify. It doesn't
> depend on the pushscript code or config files. It takes an ordinary
> yum.conf file as input. It can be configured with Fedora Account System
> account details for package owner db access outside fedora infrastructure.
> All it needs is Yum post 2.6.1 with checkForObsolete.

That sounds to me like the way forward. mmcgrath, nirik, do we have a
new-enough yum for it?

> Whether

We IMHO really need a dep checker script.

> and how often to run a script like that,

How long does it take to run? I'd say if it doesn't consume to many
resources it'd say at least two, better three times a week. Once a week
is the minimum I'd say.

> whether or not to include
> "testing"

For EPEL we afaics need to run it one without testing and once with.
Only then we notice if a dep is broken in stable and only then people
will tell the signers to push a new build to stable quickly to fix the
issue properly.

> or needsign 

Not sure. I don't think that's worth the trouble.

> (*without* multilib, ExcludeArch, Exclusive}Arch),

Multilib-checks likely need to be done.

> whether to run against CentOS or the private RHEL repos

I'd prefer the private RHEL repos if that's possible without to much
trouble. CentOS would be fine as well, but there are small differences
(no PPC (yet) for example; small delay with updates, new releases)

>, I don't want to decide.

I'd finding the answers should be that hard. I'd even say we should be
able to do this quickly here on the list.

> I would appreciate if somebody else took over. 

mmcgrath, nirik?

> [...]

Cu
knurd


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]