9:15 a.m.
Just with my previous message. I've suggested the need of having the
nvidia beta driver provided from a separate repository.
Actually there are others cases where it would be needed:
-vlc is now at 0.9.x but still has very hard regression (VLM, vlvc,
interaction with dependents software) from 0.8.6x, which last is
officially unsupported (despite the unreleased 0.8.7 version is here to
collect patches).
- ieee1394 stack is still needed for some driver like
http://www.ffado.org/ (it may also need compat-libraw1394 unless the
dual stack mode works).
- Experimental packages (that do not fit Fedora guideline yet) could
benefit to be widely distributed. (I'm think of freevo from my personal
repository right now, which isn't ready for review yet).
- Might be other needs...
For theses needs, the current design of the rpmfusion repositories
doesn't provide a solution yet.
So this repository could be defined as such:
- Reserved for developers, experienced users, adviced users.
- What unstable means here isn't only beta software, but also
* software that was not qualified as stable on a given "Fedora ABI
freeze", thus can lead to packages interaction problem. (vlc updated to
0.9.x / libraries such as ffmpeg with ABI/API bump for testing before to
update in rpmfusion-stable).
* Technology choices not keepted (ieee1394/juju) but still having
regression for some special use (ffado)
- Repository shouldn't be activated by default in any case (no kmod for
all kernels will be garanted, so better to use akmod ).
- Users shouldn't use "wide update" but only targeted update.
(like yum update --enablerepo=rpmfusion-unstable xorg-x11-drv-nvidia)
- Package replacement could be allowed from either Fedora/RPMFusion but
should be prevented for "long term"/or common use, specially when an
alternative solution is possible.
- Repository requirement will be unsorted but may needs dependencies
with fedora only, rpmfusion_free and rpmfusion_nonfree.
(there will not be an unstable repository for each possibility of
interaction).
- Do you see others case where it would be needed?
- It it doable to implement cleanly on the buildsys?
(I May try to help at the admin level if needed).
IMO it doesn't matter to have it ready to open rpmfusion (if even we
are ready). So there is no timeline for this feature. But it could be at
least discussed.
Nicolas (kwizart)
9:18 a.m.
Nicolas Chauvet (kwizart) pisze:
Just with my previous message. I've suggested the need of having
the
nvidia beta driver provided from a separate repository.
Actually there are others cases where it would be needed:
-vlc is now at 0.9.x but still has very hard regression (VLM, vlvc,
interaction with dependents software) from 0.8.6x, which last is
officially unsupported (despite the unreleased 0.8.7 version is here to
collect patches).
- ieee1394 stack is still needed for some driver like
http://www.ffado.org/ (it may also need compat-libraw1394 unless the
dual stack mode works).
- Experimental packages (that do not fit Fedora guideline yet) could
benefit to be widely distributed. (I'm think of freevo from my personal
repository right now, which isn't ready for review yet).
- Might be other needs...
For theses needs, the current design of the rpmfusion repositories
doesn't provide a solution yet.
So this repository could be defined as such:
- Reserved for developers, experienced users, adviced users.
- What unstable means here isn't only beta software, but also
* software that was not qualified as stable on a given "Fedora ABI
freeze", thus can lead to packages interaction problem. (vlc updated to
0.9.x / libraries such as ffmpeg with ABI/API bump for testing before to
update in rpmfusion-stable).
* Technology choices not keepted (ieee1394/juju) but still having
regression for some special use (ffado)
- Repository shouldn't be activated by default in any case (no kmod for
all kernels will be garanted, so better to use akmod ).
- Users shouldn't use "wide update" but only targeted update.
(like yum update --enablerepo=rpmfusion-unstable xorg-x11-drv-nvidia)
- Package replacement could be allowed from either Fedora/RPMFusion but
should be prevented for "long term"/or common use, specially when an
alternative solution is possible.
- Repository requirement will be unsorted but may needs dependencies
with fedora only, rpmfusion_free and rpmfusion_nonfree.
(there will not be an unstable repository for each possibility of
interaction).
- Do you see others case where it would be needed?
- It it doable to implement cleanly on the buildsys?
(I May try to help at the admin level if needed).
IMO it doesn't matter to have it ready to open rpmfusion (if even we
are ready). So there is no timeline for this feature. But it could be at
least discussed.
Nicolas (kwizart)
sdlmame intermediate releases would also fit nice in this.
Julian
9:31 a.m.
On 11.10.2008 11:15, Nicolas Chauvet (kwizart) wrote:
Just with my previous message. I've suggested the need of having
the
nvidia beta driver provided from a separate repository.
Actually there are others cases where it would be needed:
-vlc is now at 0.9.x but still has very hard regression (VLM, vlvc,
interaction with dependents software) from 0.8.6x, which last is
officially unsupported (despite the unreleased 0.8.7 version is here to
collect patches).
- ieee1394 stack is still needed for some driver like
http://www.ffado.org/ (it may also need compat-libraw1394 unless the
dual stack mode works).
- Experimental packages (that do not fit Fedora guideline yet) could
benefit to be widely distributed. (I'm think of freevo from my personal
repository right now, which isn't ready for review yet).
- Might be other needs...
Heck can we *please* get the real RPM Fusion running properly before
spending much time to discuss things like this(¹). There is enough to do
for people with spare cycles! Like the package with the mock configs for
test building RPM Fusion packages. I heard about ten request for it, but
nobody started to work on it after I ask here a few weeks ago :-(
(¹) I think even the whole spins stuff came up to early...
For theses needs, the current design of the rpmfusion repositories
doesn't provide a solution yet. [...]
Check the archives. We right from the start agreed that we might do
additional repos where things like those you outline can be done *once*
we have the main repos in place.
Cu
knurd
10:59 a.m.
2008/10/11 Thorsten Leemhuis <fedora(a)leemhuis.info>:
On 11.10.2008 11:15, Nicolas Chauvet (kwizart) wrote:
...
people with spare cycles! Like the package with the mock configs for
test
building RPM Fusion packages. I heard about ten request for it, but nobody
started to work on it after I ask here a few weeks ago :-(
I will take care of this today. Will answer theses message for the
particulars question that I need to raise about this.
which name for each packages ? (as i expect
(¹) I think even the whole spins stuff came up to early...
Why
is this too early to discuss ? Could you elaborate?
I can agree that it could be too early to provide an "official iso".
But experimentation is appreciated.
> For theses needs, the current design of the rpmfusion
repositories
> doesn't provide a solution yet. [...]
Check the archives. We right from the start agreed that we might do
additional repos where things like those you outline can be done *once* we
have the main repos in place.
Again, this is no timeline. But to make a draw:
"Nvidia driver packages design" Requires "repository design".
"Update vlc version" design Requires "repository design"
There are workarounds but it would be better for the workarounds to be
provided from rpmfusion itself somehow, sooner or later.
Now I don't think we can reference the whole mailing list for a design
reference of suches features.
So i'm thinking of having a wiki page for Features_accepted
Features_discussed along with a page that would sum-up accurately
those features. (this could include "proprietary graphic drivers
parallel installable" description for example).
Nicolas (kwizart)
Cu
knurd
12:38 p.m.
On 11.10.2008 12:59, KH KH wrote:
2008/10/11 Thorsten Leemhuis <fedora(a)leemhuis.info>:
> On 11.10.2008 11:15, Nicolas Chauvet (kwizart) wrote:
...
> people with spare cycles! Like the package with the mock configs for test
> building RPM Fusion packages. I heard about ten request for it, but nobody
> started to work on it after I ask here a few weeks ago :-(
I will take care of this today.
thx
Will answer theses message for the
particulars question that I need to raise about this.
which name for each packages ? (as i expect
> (¹) I think even the whole spins stuff came up to early...
Why is this too early to discuss? Could you elaborate?
Well at least from my point of view it's like this: I trying to sort out
the remaining issues I see (¹) so we can officially launch RPM Fusion as
soon as possible. But if new ideas come up (like unstable repos; a
official spin) then I have to stop that work and get involved into those
discussion if there is something that I dislike or something where
people want to get my opinion.
(¹) everyone is encouraged to help; there is still a lot to fo afaics
(I'll try to post a updated "remain steps to get rpm fusion started"
mail later today/tomorrow")
I can agree that it could be too early to provide an "official
iso".
But experimentation is appreciated.
I didn't stop anybody -- I just suggested that focusing on getting the
remaining issues sorted out would IMHO be the better idea before working
on the overnext steps.
>> For theses needs, the current design of the rpmfusion
repositories
>> doesn't provide a solution yet. [...]
> Check the archives. We right from the start agreed that we might do
> additional repos where things like those you outline can be done *once* we
> have the main repos in place.
Again, this is no timeline. But to make a draw:
"Nvidia driver packages design" Requires "repository design".
"Update vlc version" design Requires "repository design"
There are workarounds but it would be better for the workarounds to be
provided from rpmfusion itself somehow, sooner or later.
Can't follow. Can you try to rephrase?
Now I don't think we can reference the whole mailing list for a
design
reference of suches features.
So i'm thinking of having a wiki page for Features_accepted
Features_discussed along with a page that would sum-up accurately
those features. (this could include "proprietary graphic drivers
parallel installable" description for example).
There have been such pages in the wiki (in RPM Fusion or Fedora), but
they in my experience often tend to get outdated quickly and then are
more misleading then helpful. But it works fine if someone has the
energy to keep things up to date. But I warn you, that is a whole lot of
work afaics.
CU
knurd
1:03 p.m.
On Sat, 2008-10-11 at 11:15 +0200, Nicolas Chauvet (kwizart) wrote:
- ieee1394 stack is still needed for some driver like
http://www.ffado.org/
I've got a local ffado package that works w/the new stack.
(it may also need compat-libraw1394 unless the
dual stack mode works).
It does, but its only available in F10, iirc.
--jarod
5685
days inactive
5685
days old
rpmfusion-developers@lists.rpmfusion.org
5 comments
4 participants
participants (4)
-
Jarod Wilson -
Julian Sikorski -
Nicolas Chauvet -
Thorsten Leemhuis