10:18 p.m.
Hi,
Since I'm new with packaging for a 3rd part repo I need to get certain things clear.
What is the policy whenever Fedora pushes new packages to its updates repo and that breaks
package dependencies of rpmfusion?
For instance, right now xmms-*.rpm packages are updated in Fedora and yum says:
----------------------------------------------
Resolving Dependencies
--> Running transaction check
--> Processing Dependency: xmms-libs = 1:1.2.10 for package: xmms-mp3
---> Package xmms-libs.i386 1:1.2.11-1.20071117cvs.1.fc9 set to be updated
--> Finished Dependency Resolution
xmms-mp3-1.2.10-6.fc9.x86_64 from installed has depsolving problems
--> Missing Dependency: xmms-libs = 1:1.2.10 is needed by package
xmms-mp3-1.2.10-6.fc9.x86_64 (installed)
Error: Missing Dependency: xmms-libs = 1:1.2.10 is needed by package
xmms-mp3-1.2.10-6.fc9.x86_64 (installed)
----------------------------------------------
There might be cases where the package maintainer (xmms-mp3) is not around (sleeping, on a
trip, in depression etc.). How do we solve such a problem then? For example, in this case
I can fix the problem in the cvs right away, since I'm one of the few avaliable people
at this hour, but I don't know if I'm supposed to. Or if I do fix the problem in
cvs, would it be considered rude?
Well if I do, then there is also a package signing step. Is this done manually?
In fedora, there are ueberpackagers who can access/modify other people's packages. Do
we have such a hierarchy system in rpmfusion?
This ends my flood of questions (for now) :)
Cheers,
-oget
12:13 p.m.
BTW, some will have noticed already: I was traveling for two days (and
have been a bit busy right before that) and I'm making my way through
the mail backlog...
On 08.10.2008 00:18, Orcan Ogetbil wrote:
Since I'm new with packaging for a 3rd part repo I need to get
certain things clear.
Note that the problems you outline can happen similarly within the
Fedora repos as well.
What is the policy whenever Fedora pushes new packages to its
updates
repo and that breaks package dependencies of rpmfusion?
There are no real policies that handle this situation except "that
should not happen and hence packagers should do everything to prevent
that from happening".
For instance, right now xmms-*.rpm packages are updated in Fedora
and
yum says:
[...]
There might be cases where the package maintainer (xmms-mp3) is not
around (sleeping, on a trip, in depression etc.). How do we solve
such a problem then?
The usual answer is: File a bug, it's up to the maintainers to fix it.
But that of course is not the quickest way to fix this and thus no real
solution :-/ Sometimes it takes days or weeks until the problem gets
fixed that way.
In livna I now and then after a while simply went forwarded and just
fixed the problem without waiting for the maintainer. Like I fixed the
xmms-mp3 problem there (xmms-mp3 hasn't had a real owner there, so I
could just do it directly) a few days ago with a updated spec file I got
from Paul (the xmms maintainer in Fedora). I forwarded it to Xavier (who
maintains xmms-mp3 for RPM Fusion), but afaics he didn't commit it for
RPM Fusion yet (maybe I should have told him more about the backgrounds,
but I was in a rush...).
But simply fixing a issue like that often might have side effects
someone that is not really familiar with the package doesn't know about.
Sometimes those are that bad that it might be better to leave things
broken until the package maintainer (or someone else that is familiar
with the package) has a proper (interim-) solution.
So each of those problems need to be fixed differently. Maybe we can
work out policies to handle those situations more efficient in the
future, but I'm not sure if that really is worth the work. I'd say for
now we just wait and look how things work out.
For example, in this case I can fix the problem
in the cvs right away, since I'm one of the few avaliable people at
this hour, but I don't know if I'm supposed to. Or if I do fix the
problem in cvs, would it be considered rude?
Yes, it would.
Well if I do, then there is also a package signing step. Is this
done
manually?
Yes.
In fedora, there are ueberpackagers who can access/modify other
people's packages. Do we have such a hierarchy system in rpmfusion?
Sort of. The cvsadmins (Xavier, hansg and I) can commit everywhere. I'd
say that should do the trick for now, as those problems hopefully should
not happen that often.
Cu
knurd
6:55 a.m.
Thorsten Leemhuis wrote:
On 08.10.2008 00:18, Orcan Ogetbil wrote:
> Since I'm new with packaging for a 3rd part repo I need to get
> certain things clear.
Note that the problems you outline can happen similarly within the
Fedora repos as well.
> What is the policy whenever Fedora pushes new packages to its updates
> repo and that breaks package dependencies of rpmfusion?
There are no real policies that handle this situation except "that
should not happen and hence packagers should do everything to prevent
that from happening".
For the average joe using the gui tools, ie package kit,
and it's update
notifier, I think it works out nicely enough:
- you have 10 security and 6 updates available.
- update me
- downloads, tests, updates with skip-broken capability, leaving only
the broken ones still outstanding.
- when the metadata is checked again, joe does get told again about the
outstanding update, but the update attempt again informs of missing or
incomplete package.
The last bit could be a bit annoying, and the process holds off updating
that {potential security} issue until the package becomes available.
Are there scripts available eg from fedora that could be used by
rpmfusion to create a list of broken packages, aka fedora's, and
automatically email the maintainer, as well as adding to the package
creation report ? The sooner s/he knows about the issue, the sooner a
fix or rebuild can be requested.
How common is it that a simple bump, build and push is all that is needed ?
DaveT.
7:44 a.m.
On 12.10.2008 08:55, David Timms wrote:
Thorsten Leemhuis wrote:
> On 08.10.2008 00:18, Orcan Ogetbil wrote:
>> Since I'm new with packaging for a 3rd part repo I need to get
>> certain things clear.
> Note that the problems you outline can happen similarly within the
> Fedora repos as well.
>
>> What is the policy whenever Fedora pushes new packages to its updates
>> repo and that breaks package dependencies of rpmfusion?
> There are no real policies that handle this situation except "that
> should not happen and hence packagers should do everything to prevent
> that from happening".
For the average joe using the gui tools, ie package kit, and it's update
notifier, I think it works out nicely enough:
- you have 10 security and 6 updates available.
- update me
- downloads, tests, updates with skip-broken capability, leaving only
the broken ones still outstanding.
- when the metadata is checked again, joe does get told again about the
outstanding update, but the update attempt again informs of missing or
incomplete package.
The last bit could be a bit annoying, and the process holds off updating
that {potential security} issue until the package becomes available.
Are there scripts available eg from fedora that could be used by
rpmfusion to create a list of broken packages, aka fedora's, and
automatically email the maintainer, as well as adding to the package
creation report? The sooner s/he knows about the issue, the sooner a
fix or rebuild can be requested.
mschwendt ran the dep-checker scripts a few weeks ago (see archives).
Xavier afaik is working on setting those up properly, to make sure they
run with each of our pushes.
How common is it that a simple bump, build and push is all that is
needed ?
From my experience from livna: Not that common; most of the more then a
bump is needed.
Cu
knurd
10:56 a.m.
On Sun, 12 Oct 2008 09:44:06 +0200, Thorsten Leemhuis wrote:
> Are there scripts available eg from fedora that could be used by
> rpmfusion to create a list of broken packages, aka fedora's, and
> automatically email the maintainer, as well as adding to the package
> creation report? The sooner s/he knows about the issue, the sooner a
> fix or rebuild can be requested.
mschwendt ran the dep-checker scripts a few weeks ago (see archives).
Xavier afaik is working on setting those up properly, to make sure they
run with each of our pushes.
A little bit of work is needed to support multiple owners.list files
(I have that on my TODO list). The old API for that can be obsoleted as it
moved forward to using the fedora pkgdb as the primary method to retrieve
pkg owner details.
12:11 a.m.
In livna I now and then after a while simply went forwarded
and just
fixed the problem without waiting for the maintainer. Like
I fixed the
xmms-mp3 problem there (xmms-mp3 hasn't had a real
owner there, so I
could just do it directly) a few days ago with a updated
spec file I got
from Paul (the xmms maintainer in Fedora). I forwarded it
to Xavier (who
maintains xmms-mp3 for RPM Fusion), but afaics he
didn't commit it for
RPM Fusion yet (maybe I should have told him more about the
backgrounds,
but I was in a rush...).
But simply fixing a issue like that often might have side
effects
someone that is not really familiar with the package
doesn't know about.
Sometimes those are that bad that it might be better to
leave things
broken until the package maintainer (or someone else that
is familiar
with the package) has a proper (interim-) solution.
I understand. But we shouldn't forget that all such issues will build up
towards the reputation of the repository in user's mind, and in turn, towards the
reputation of Fedora.
So each of those problems need to be fixed differently.
Maybe we can
work out policies to handle those situations more efficient
in the
future, but I'm not sure if that really is worth the
work. I'd say for
now we just wait and look how things work out.
Yes, let have things settled first; but in the future a warn-the-maintainer
mechanism as was suggested will surely smoothen things out.
I just wanted to brainstorm about an issue that I found important but I also know that
people are busy with other important things. It was my 2 cents.
Peace,
-oget
5696
days inactive
5702
days old
rpmfusion-developers@lists.rpmfusion.org
5 comments
4 participants
participants (4)
-
Agnes Jones -
Michael Schwendt -
Orcan Ogetbil -
Thorsten Leemhuis