Last week, I have prepared a draft document detailing how to go on with KDE 4 in Fedora as I see it: http://fedoraproject.org/wiki/KevinKofler/F8KDE4Plan
This has already gotten some quick looks and positive reactions at last week's KDE SIG meeting. However, not all interested parties were present. Now that the CVS devel branch has unfrozen for Fedora 8, I think it's time to subject this to broader discussion.
Once a plan is agreed on, we need to put the result (something like this document, probably this document with some edits) into a more official namespace on the wiki.
Kevin Kofler
On 21.05.2007 16:51, Kevin Kofler wrote:
Last week, I have prepared a draft document detailing how to go on with KDE 4 in Fedora as I see it: http://fedoraproject.org/wiki/KevinKofler/F8KDE4Plan
Quoting from that page:
With Fedora 7 scheduled for the end of this month, assuming the usual 6-month release cycle for Fedora 8 ("F8"), this means F8 will be released somewhere around the end of November.
There were some *discussion* about Fedora making a more strict releases cycle somewhat aligned to the Gnome release cycle. There was afaik no outcome from those discussions yet, but well, before starting to realize those KDE plans it might be better to see the F8 release schedule first.
Even with the current proposed scheme and the estimated Fedora 8 release date according to the old behavior I'd tend to say that schedule is quite ambitious -- just let KDE 4.0 slip two or four weeks and the release of Fedora**8 gets in trouble.
Further: all the important people are busy with F7. I'd say this kind of discussion would be better held after F7 is ready.
CU thl
On Tue, 2007-05-22 at 06:55 +0200, Thorsten Leemhuis wrote:
On 21.05.2007 16:51, Kevin Kofler wrote:
Last week, I have prepared a draft document detailing how to go on with KDE 4 in Fedora as I see it: http://fedoraproject.org/wiki/KevinKofler/F8KDE4Plan
Quoting from that page:
With Fedora 7 scheduled for the end of this month, assuming the usual 6-month release cycle for Fedora 8 ("F8"), this means F8 will be released somewhere around the end of November.
There were some *discussion* about Fedora making a more strict releases cycle somewhat aligned to the Gnome release cycle. There was afaik no outcome from those discussions yet, but well, before starting to realize those KDE plans it might be better to see the F8 release schedule first.
Even with the current proposed scheme and the estimated Fedora 8 release date according to the old behavior I'd tend to say that schedule is quite ambitious -- just let KDE 4.0 slip two or four weeks and the release of Fedora**8 gets in trouble.
Further: all the important people are busy with F7. I'd say this kind of discussion would be better held after F7 is ready.
CU thl
You could always release KDE 4.0RCx (as long as it's semi-stable) and switch to 4.0 release once it's out. It's not like its never been done before. (Again, assuming that KDE 4.0 reaches a certain maturity during F8 test3/4)
- Gilboa
On 22.05.2007 09:39, Gilboa Davara wrote:
On Tue, 2007-05-22 at 06:55 +0200, Thorsten Leemhuis wrote:
On 21.05.2007 16:51, Kevin Kofler wrote:
Last week, I have prepared a draft document detailing how to go on with KDE 4 in Fedora as I see it: http://fedoraproject.org/wiki/KevinKofler/F8KDE4Plan
Quoting from that page:
With Fedora 7 scheduled for the end of this month, assuming the usual 6-month release cycle for Fedora 8 ("F8"), this means F8 will be released somewhere around the end of November.
There were some *discussion* about Fedora making a more strict releases cycle somewhat aligned to the Gnome release cycle. There was afaik no outcome from those discussions yet, but well, before starting to realize those KDE plans it might be better to see the F8 release schedule first.
Even with the current proposed scheme and the estimated Fedora 8 release date according to the old behavior I'd tend to say that schedule is quite ambitious -- just let KDE 4.0 slip two or four weeks and the release of Fedora**8 gets in trouble.
Further: all the important people are busy with F7. I'd say this kind of discussion would be better held after F7 is ready.
You could always release KDE 4.0RCx (as long as it's semi-stable) and switch to 4.0 release once it's out. It's not like its never been done before. (Again, assuming that KDE 4.0 reaches a certain maturity during F8 test3/4)
Well, we did that with Gnome for example -- but we know that Gnome releases happen nearly always when they are scheduled.
Other stuff -- say thunderbird 2.0 for F7 -- afaics get added to rawhide only when they looked stabled and the release was foreseeable to happen before the next Fedora is out.
IOW: It's IMHO way to early to discuss replacing KDE 3.5.x in rawhide with KDE 4.0.
My vote would be to maintain two (one for rawhide, one for F7) add-on repos dedicated to KDE 4.0 *within* the Fedora project somewhere (¹). If everything looks promising by the feature freeze for F8 (or earlier) just import it to rawhide.
CU thl
(¹) -- I have a proposal for such a general testing and kmod repo in the scope of the Fedora project. I've written that on the fight back from Fudcon Boston, but did not release it, as we have bigger problems to solve ATM before we start thinking about stuff like that
Thorsten Leemhuis <fedora <at> leemhuis.info> writes:
There were some *discussion* about Fedora making a more strict releases cycle somewhat aligned to the Gnome release cycle. There was afaik no
Yuck, I'd sure hope the Fedora release schedule won't get aligned on the GNOME schedule at the expense of KDE... :-(
If the schedule gets aligned on a desktop's schedule at all, I'd suggest aligning it on the KDE 4 schedule, that brings major new features, it's not a boring point release like GNOME. But the usual 6-month schedule gives essentially the same result while staying desktop-neutral.
About slippage, from recent history, I'd think Fedora is at least as likely to slip as KDE is, so I'd expect more slack between KDE 4.0's release and F8's, not less. ;-) And if KDE really slips a lot more than Fedora (we have about a month of slack time assuming a 6-month schedule), we can always include an RC and upgrade later, as was done for OO.o 2, one or two GNOME releases, several kernel releases etc.
As I already said in a previous discussion, it's a lot safer to include an RC which got regular testing in Rawhide than to include a release at the last moment with no testing of integration within Fedora. That's also why I want the alpha in Rawhide ASAP. IMHO, we could wait for the feature freeze (June 1st) or the beta (June 25), but not more. IMHO, we really need KDE 3.9?.* in test1.
Kevin Kofler
Once upon a time Tuesday 22 May 2007, Kevin Kofler wrote:
Thorsten Leemhuis <fedora <at> leemhuis.info> writes:
As I already said in a previous discussion, it's a lot safer to include an RC which got regular testing in Rawhide than to include a release at the last moment with no testing of integration within Fedora. That's also why I want the alpha in Rawhide ASAP. IMHO, we could wait for the feature freeze (June 1st) or the beta (June 25), but not more. IMHO, we really need KDE 3.9?.* in test1.
I think we should aim for KDE4 for F8 and get it in ASAP but have KDE3 usable and installable also. there will be alot of apps that will not get ported in time. se we will need kdelibs and kdebase from kde 3 so we should have it as an option
Dennis
Dennis Gilmore <dennis <at> ausil.us> writes:
I think we should aim for KDE4 for F8 and get it in ASAP but have KDE3 usable and installable also. there will be alot of apps that will not get ported in time. se we will need kdelibs and kdebase from kde 3 so we should have it as an option
That's part of the plan I linked to. :-) Upstream wants to guarantee kdelibs parallel-installation without conflicts (and AFAIK they're there or almost there), so a complete compat-kdelibs3 should be possible (though unfortunately the -devel packages will have to conflict as usual for compat libraries), and much of kdebase 3 is also possible to ship in a compat-kdebase3: things like KControl modules, styles etc., but not the kdebase applications (konqueror, kwrite etc.) which would both conflict and be redundant with the KDE 4 equivalents.
The idea is that the workspace (WM, desktop, taskbar) will come from KDE 4, but KDE 3 apps will still be usable.
Kevin Kofler
On Tue, 2007-05-22 at 12:49 +0000, Kevin Kofler wrote:
Dennis Gilmore <dennis <at> ausil.us> writes:
I think we should aim for KDE4 for F8 and get it in ASAP but have KDE3 usable and installable also. there will be alot of apps that will not get ported in time. se we will need kdelibs and kdebase from kde 3 so we should have it as an option
That's part of the plan I linked to. :-) Upstream wants to guarantee kdelibs parallel-installation without conflicts (and AFAIK they're there or almost there), so a complete compat-kdelibs3 should be possible (though unfortunately the -devel packages will have to conflict as usual for compat libraries),
Why do the devel packages have to conflict? If the libs are parallel installable, the headers really should be too[1]. Otherwise, there basically has to be a flag day event for things to work. And that sucks.
Jeremy
Jeremy Katz <katzj <at> redhat.com> writes:
Why do the devel packages have to conflict? If the libs are parallel installable, the headers really should be too[1]. Otherwise, there basically has to be a flag day event for things to work. And that sucks.
I hate -devel conflicts too, but the at least the .so symlinks conflict, and the KDE people are also ignoring some other -devel type conflicts (like the kconfig_compiler executable, see http://lists.kde.org/?l=kde-core-devel&m=117947655224722&w=2 ) because they say the -devel packages can't be parallel-installed anyway due to the .so conflicts. So I don't see any other solution than a -devel conflict. :-(
Kevin Kofler
On Tue, 2007-05-22 at 21:34 +0000, Kevin Kofler wrote:
Jeremy Katz <katzj <at> redhat.com> writes:
Why do the devel packages have to conflict? If the libs are parallel installable, the headers really should be too[1]. Otherwise, there basically has to be a flag day event for things to work. And that sucks.
I hate -devel conflicts too, but the at least the .so symlinks conflict,
Then things *aren't* parallel installable.
and the KDE people are also ignoring some other -devel type conflicts (like the kconfig_compiler executable, see http://lists.kde.org/?l=kde-core-devel&m=117947655224722&w=2 ) because they say the -devel packages can't be parallel-installed anyway due to the .so conflicts. So I don't see any other solution than a -devel conflict. :-(
Conflicts like this just aren't acceptable to have in Fedora because now _I_ as a developer have to choose which I'm developing apps for. And if I'm just building apps that I find online, I'm going to be wanting to build for both APIs.
And that makes our user experience suck. If upstream doesn't see that, then it might be worth doing like we've had to do for some other libraries to get fully parallel installable even if it's not the path of upstream :( But one would hope that when presented with reason and patches, upstream would be willing to come along. Because every other distribution is going to have the same questions, concerns and problems
Jeremy
Jeremy Katz <katzj <at> redhat.com> writes:
I hate -devel conflicts too, but the at least the .so symlinks conflict,
Then things *aren't* parallel installable.
A lot of compat libs work like that, the runtime packages with the versioned so-s are parallel installable, the -devel packages conflict.
This is also what upstream KDE is planning to deliver.
Conflicts like this just aren't acceptable to have in Fedora because now _I_ as a developer have to choose which I'm developing apps for. And if
Guess why I hate them too. There's the possibility of switching between the packages or of using a mock chroot, but that sucks.
I'm just building apps that I find online, I'm going to be wanting to build for both APIs.
Same as above.
And that makes our user experience suck. If upstream doesn't see that, then it might be worth doing like we've had to do for some other libraries to get fully parallel installable even if it's not the path of upstream :(
Sure I could patch the heck out of KDE to install the symlinks into /usr/lib/kde[34], rename conflicting binaries etc., but then we'd probably have to patch the heck out of all applications building against it. KDE doesn't use pkg-config, and kde-config has no --libs option where you can easily add a -L foo option. And this doesn't even cover stuff like kconfig_compiler.
Or we could install one of the 2 KDE versions into a custom prefix like /opt/kde3 or /opt/kde4, and in fact this is what my current kde*4 packages do, but then good bye FHS.
But one would hope that when presented with reason and patches, upstream would be willing to come along. Because every other distribution is going to have the same questions, concerns and problems
Rex Dieter, I think you have the best contacts upstream, could you please take this up with them?
But I'm not sure about the "every other distribution" part. OpenSUSE had KDE 3 in /opt/kde3, so they're not affected by most of this, and the others probably just have the -devel packages conflict.
Kevin Kofler
PS:
But I'm not sure about the "every other distribution" part. OpenSUSE had KDE 3 in /opt/kde3, so they're not affected by most of this, and the others probably just have the -devel packages conflict.
Oh, and Gentoo isn't going to care either, as they use a system called "slots", where they install every single version of KDE, even point releases, with its own prefix (/usr/kde-$VERSION).
So I fear we're pretty much alone on this. :-(
Kevin Kofler
On Tue, 2007-05-22 at 22:31 +0000, Kevin Kofler wrote:
Jeremy Katz <katzj <at> redhat.com> writes:
I hate -devel conflicts too, but the at least the .so symlinks conflict,
Then things *aren't* parallel installable.
A lot of compat libs work like that, the runtime packages with the versioned so-s are parallel installable, the -devel packages conflict.
This is also what upstream KDE is planning to deliver.
This doesn't actually help anyone, though :(
Conflicts like this just aren't acceptable to have in Fedora because now _I_ as a developer have to choose which I'm developing apps for. And if
Guess why I hate them too. There's the possibility of switching between the packages or of using a mock chroot, but that sucks.
Yes. A lot.
I'm just building apps that I find online, I'm going to be wanting to build for both APIs.
Same as above.
And that makes our user experience suck. If upstream doesn't see that, then it might be worth doing like we've had to do for some other libraries to get fully parallel installable even if it's not the path of upstream :(
Sure I could patch the heck out of KDE to install the symlinks into /usr/lib/kde[34], rename conflicting binaries etc., but then we'd probably have to patch the heck out of all applications building against it. KDE doesn't use pkg-config, and kde-config has no --libs option where you can easily add a -L foo option. And this doesn't even cover stuff like kconfig_compiler.
Or the case could be made to upstream as to why this is important. Otherwise, I think it's going to be really hard to move Fedora to KDE4 until things are ported and we can drop kdelibs3 compatibility.
Or we could install one of the 2 KDE versions into a custom prefix like /opt/kde3 or /opt/kde4, and in fact this is what my current kde*4 packages do, but then good bye FHS.
Yeah, that's not very ideal either.
But one would hope that when presented with reason and patches, upstream would be willing to come along. Because every other distribution is going to have the same questions, concerns and problems
Rex Dieter, I think you have the best contacts upstream, could you please take this up with them?
But I'm not sure about the "every other distribution" part. OpenSUSE had KDE 3 in /opt/kde3, so they're not affected by most of this, and the others probably just have the -devel packages conflict.
The problem for us is that conflicts are very very strongly discouraged, especially for things that are as prominent as KDE. While the guidelines do allow for a cop-out of it not being possible sometimes with compat packages, that's really in the "it should be avoided" category and doing it for huge swaths like "KDE3 development" is just going to suck as far as providing a good KDE experience.
The right answer here really is that we need people to get involved and work with upstream to make this sane. As much as it will be painful to point them at something written by Havoc, the points there are incredibly salient and very true. Otherwise, it might be wise just to keep KDE 4 entirely on the sidelines (in side paths or whatever) until it's matured to the point that the worry for KDE3 apps, etc is reduced
Jeremy
Jeremy Katz <katzj <at> redhat.com> writes:
Or we could install one of the 2 KDE versions into a custom prefix like /opt/kde3 or /opt/kde4, and in fact this is what my current kde*4 packages do, but then good bye FHS.
Yeah, that's not very ideal either.
I have another idea: maybe we could: * have the non-devel stuff (which doesn't conflict) in /usr * in the kdelibs3-devel package: - create a /usr/kde3.5 (or whatever Gentoo uses, so existing packages should be prepared to deal with that setup already) - symlink all the kdelibs3 stuff in /usr into there - add the -devel stuff (which does conflict) as regular files (not symlinks) - point kde-config (not kde4-config) to /usr/kde3.5
I wonder how workable that idea would be.
Kevin Kofler
On Tue, 2007-05-22 at 23:17 +0000, Kevin Kofler wrote:
Jeremy Katz <katzj <at> redhat.com> writes:
Or we could install one of the 2 KDE versions into a custom prefix like /opt/kde3 or /opt/kde4, and in fact this is what my current kde*4 packages do, but then good bye FHS.
Yeah, that's not very ideal either.
I have another idea: maybe we could:
[snip]
I wonder how workable that idea would be.
Sounds like it might work. And while /usr/kde3.5 (or whatever) is somewhat breaking the FHS, it's definitely better than /opt[1] and probably better than the alternative of conflicting packages.
Jeremy
[1] Since we try to really leave /opt for non-package-managed software. For the silly people that use such stuff :-)
Le Mer 23 mai 2007 01:26, Jeremy Katz a écrit :
Sounds like it might work. And while /usr/kde3.5 (or whatever) is somewhat breaking the FHS,
"somewhat" breaking. Yes, sure. Is avoiding conflicts in *devel* packages for *compat* stuff suddenly worth breaking conventions? Seems just digging ourselves deeper in the mess to me.
On Wed, 2007-05-23 at 09:19 +0200, Nicolas Mailhot wrote:
Le Mer 23 mai 2007 01:26, Jeremy Katz a écrit :
Sounds like it might work. And while /usr/kde3.5 (or whatever) is somewhat breaking the FHS,
"somewhat" breaking. Yes, sure. Is avoiding conflicts in *devel* packages for *compat* stuff suddenly worth breaking conventions? Seems just digging ourselves deeper in the mess to me.
If it's compat stuff that we expect users to care about and with a good sized audience (as opposed to something like compat-plib where the audience is pretty small), yes, it may well be worth it. I'd far rather things just get resolved nicely upstream, though. Don't get me wrong there
Jeremy
Le Mer 23 mai 2007 01:17, Kevin Kofler a écrit :
I have another idea: maybe we could:
- have the non-devel stuff (which doesn't conflict) in /usr
- in the kdelibs3-devel package:
- create a /usr/kde3.5 (or whatever Gentoo uses, so existing packages
should be
Please no. -devel conflicts are a lot better than adding new roots. And they shouldn't matter with a proper mock setup
On Wed, 2007-05-23 at 09:15 +0200, Nicolas Mailhot wrote:
Le Mer 23 mai 2007 01:17, Kevin Kofler a écrit :
I have another idea: maybe we could:
- have the non-devel stuff (which doesn't conflict) in /usr
- in the kdelibs3-devel package:
- create a /usr/kde3.5 (or whatever Gentoo uses, so existing packages
should be
Please no. -devel conflicts are a lot better than adding new roots. And they shouldn't matter with a proper mock setup
This is not true. They matter to users that want to build both kde3 and kde4 apps on their systems.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a leather-clad amnesiac grifter with a robot buddy named Sparky. She's a high-kicking hypochondriac magician's assistant with a birthmark shaped like Liberty's torch. They fight crime!
Le Mer 23 mai 2007 09:33, Alexander Larsson a écrit :
On Wed, 2007-05-23 at 09:15 +0200, Nicolas Mailhot wrote:
Please no. -devel conflicts are a lot better than adding new roots. And they shouldn't matter with a proper mock setup
This is not true. They matter to users that want to build both kde3 and kde4 apps on their systems.
I didn't say they didn't matter. I said that given other technical solutions exist, and given that breaking our filesystem organisation has its own drawbacks, -devel conflicts were probably not the worst solution.
A conflict is a short-term fix that can be removed pretty much as soon as it's no longuer necessary. Filesystem choices OTOH are a major PITA to change later because they touch so much stuff (user/packager/developer habits/scripts/docs, selinux policies) and tend to spread way out of the initial scope.
On Wed, 2007-05-23 at 10:23 +0200, Nicolas Mailhot wrote:
Le Mer 23 mai 2007 09:33, Alexander Larsson a écrit :
On Wed, 2007-05-23 at 09:15 +0200, Nicolas Mailhot wrote:
Please no. -devel conflicts are a lot better than adding new roots. And they shouldn't matter with a proper mock setup
This is not true. They matter to users that want to build both kde3 and kde4 apps on their systems.
I didn't say they didn't matter. I said that given other technical solutions exist, and given that breaking our filesystem organisation has its own drawbacks, -devel conflicts were probably not the worst solution.
Other solutions exist that work for you, or for me or for Alex. Not for the vast majority of users who still just download foo.tar.gz, untar it and run ./configure ; make ; make install. No mock. No rpm. Just building software. We _can't_ break the ability to do this just because "other technical solutions exist". And switching out which package you have installed depending on what you're building really isn't a "solution" so much as "ignoring the problem".
Jeremy
Nicolas Mailhot wrote:
I didn't say they didn't matter. I said that given other technical solutions exist, and given that breaking our filesystem organisation has its own drawbacks, -devel conflicts were probably not the worst solution.
Oh man, you should re-read all the nits you had over the liberation fonts. I am completely shocked that you'd even say this given how picky you were. We need to come up with a good solution to the problem, not ignore it.
Le Mer 23 mai 2007 16:31, Christopher Aillon a écrit :
Nicolas Mailhot wrote:
I didn't say they didn't matter. I said that given other technical solutions exist, and given that breaking our filesystem organisation has its own drawbacks, -devel conflicts were probably not the worst solution.
Oh man, you should re-read all the nits you had over the liberation fonts. I am completely shocked that you'd even say this given how picky you were.
Picky as in making totally unreasonable demands that made it last a terrible 4 days, sure. Remind us what is our average review time?
We need to come up with a good solution to the problem, not ignore it.
I am completely shocked you feel creating a new root under /usr is a trivial matter, given the ongoing pain of making badly-designed software or packages conform to our guidelines, the years it took to kill the X11 root, the lag we had to adopt /srv and /media, rpm (mis) handling of symlink/directory changes, interaction with selinux policies, etc
How will this stuff work with multilib? How will it interact with backup systems? How will resorption happen in one release cycle?
Who is ignoring the problems?
Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
How will this stuff work with multilib?
Depending on how exactly we pick the prefix, either there would be one symlink tree (with a few non-symlink files) under /usr/lib/kde-3.5 and one under /usr/lib64/kde-3.5, and non-multilib stuff (like the config directories) could just symlink to the same place, or the /usr/kde-3.5 prefix would be multilibbed the same way /usr is (/usr/kde-3.5/lib and /usr/kde-3.5/lib64 separate, the rest common). Either way, I don't see the problem there.
How will it interact with backup systems?
The same way any other symlinks do, if your backup systems don't handle symlinks, you already lose.
How will resorption happen in one release cycle?
It would just stay, this would only affect compat libs anyway.
And under the scheme I suggested, kdelibs3 (or compat-kdelibs or compat-kdelibs3, we're waiting for FPC for a clear naming policy there, as all 3 schemes are in use right now) wouldn't even be affected, only kdelibs3-devel would, that package you wouldn't let us keep installed at all (except at the expense of the KDE 4 kdelibs-devel), so apparently you don't need it installed anyway, so why do you care?
As for SELinux, I'm sure that working together with SELinux policy experts will get the prefix labeled correctly without any problems, assuming such labeling is needed at all (as, as I said, most of the content in that prefix would be symlinks to real files under the regular prefix under that scheme).
There might be other reasons for not using the setup I suggested, but the ones you gave weren't it. However, it is just a suggestion; we might actually end up with a completely different solution (ideally, upstream will just fix their conflicts), and rest assured that technical reasons why such a scheme wouldn't work won't be ignored. Also note that there are going to be at least 2 experienced packagers (Than Ngo and Rex Dieter) reviewing my suggestions, as they are the KDE maintainers in Fedora, I'm just the volunteer who packaged the KDE 4 developer previews.
Kevin Kofler
Le mercredi 23 mai 2007 à 21:29 +0000, Kevin Kofler a écrit :
Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
How will this stuff work with multilib? How will it interact with backup systems?
[…] Lots of stuff to make the proposed scheme work
How will resorption happen in one release cycle?
It would just stay, this would only affect compat libs anyway.
Inclination to keep the mess forever, so it will serve a example and justification to create other out-of-standard-layout roots. Hopefully the compat policy will pass first.
Now you see why I wasn't enthused about the proposal.
There might be other reasons for not using the setup I suggested, but the ones you gave weren't it.
Yes you can always make a bandaid "work" by piling more bandaids on it
However, it is just a suggestion; we might actually end up with a completely different solution (ideally, upstream will just fix their conflicts),
I sure hope so and would have let the matter rest for now if not questioned directly.
Kevin Kofler wrote:
Jeremy Katz <katzj <at> redhat.com> writes:
But one would hope that when presented with reason and patches, upstream would be willing to come along. Because every other distribution is going to have the same questions, concerns and problems
Rex Dieter, I think you have the best contacts upstream, could you please take this up with them?
parallel-installability is one of my top priorities wrt kde4. I'll ping upstream (and nag non-stop at akademy) to ensure this is resolved satisfactorily in time for kde 4.0 release.
-- Rex
On Tue, 2007-05-22 at 19:28 -0500, Rex Dieter wrote:
Kevin Kofler wrote:
Jeremy Katz <katzj <at> redhat.com> writes:
But one would hope that when presented with reason and patches, upstream would be willing to come along. Because every other distribution is going to have the same questions, concerns and problems
Rex Dieter, I think you have the best contacts upstream, could you please take this up with them?
parallel-installability is one of my top priorities wrt kde4. I'll ping upstream (and nag non-stop at akademy) to ensure this is resolved satisfactorily in time for kde 4.0 release.
Sounds good :-)
Jeremy
Rex Dieter <rdieter <at> math.unl.edu> writes:
parallel-installability is one of my top priorities wrt kde4. I'll ping upstream (and nag non-stop at akademy) to ensure this is resolved satisfactorily in time for kde 4.0 release.
Of course, that would be a bit late... The sooner this is solved satisfactorily, the better.
Kevin Kofler
Hmmm, my sentence is a bit ambiguous, so:
Rex Dieter <rdieter <at> math.unl.edu> writes:
parallel-installability is one of my top priorities wrt kde4. I'll ping upstream (and nag non-stop at akademy) to ensure this is resolved satisfactorily in time for kde 4.0 release.
Of course, that would be a bit late... The sooner this is solved satisfactorily, the better.
"that" refers to the KDE 4.0 release, not aKademy.
Kevin Kofler
See also: http://websvn.kde.org/trunk/KDE/kdelibs/CONFLICTS?view=log
It looks like we got 5 executables to take care of in one way or the other, and figure out a way to deal with the symlinks.
Kevin Kofler
Conflicts like this just aren't acceptable to have in Fedora because now _I_ as a developer have to choose which I'm developing apps for. And if I'm just building apps that I find online, I'm going to be wanting to build for both APIs.
Here is a list of all fileconflicts in FC-devel for i386. Not all are bugs, but I think it should be worth it to reduce the list a bit:
fileconflict for /etc/pam.d/imap in uw-imap-2006h-1.fc7.i386.rpm and cyrus-imapd-2.3.8-3.fc7.i386.rpm fileconflict for /etc/pam.d/pop in uw-imap-2006h-1.fc7.i386.rpm and cyrus-imapd-2.3.8-3.fc7.i386.rpm fileconflict for /usr/bin/count in fish-1.21.12-1.fc6.i386.rpm and html-xml-utils-3.7-4.fc6.i386.rpm fileconflict for /usr/bin/cs in csound-5.03.0-13.fc7.i386.rpm and clearsilver-0.10.4-3.fc7.i386.rpm fileconflict for /usr/bin/esd in esound-0.2.38-1.fc7.i386.rpm and pulseaudio-esound-compat-0.9.5-5.fc7.i386.rpm fileconflict for /usr/bin/extract in libextractor-0.5.17a-1.fc7.i386.rpm and csound-5.03.0-13.fc7.i386.rpm fileconflict for /usr/bin/extract in libextractor-0.5.17a-1.fc7.i386.rpm and html-xml-utils-3.7-4.fc6.i386.rpm fileconflict for /usr/bin/extract in csound-5.03.0-13.fc7.i386.rpm and html-xml-utils-3.7-4.fc6.i386.rpm fileconflict for /usr/bin/qstat in qstat-2.11-1.fc7.i386.rpm and torque-client-2.1.8-1.fc7.i386.rpm fileconflict for /usr/include/plib/fnt.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/js.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/netBuffer.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/netChannel.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/netMessage.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/netMonitor.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/netSocket.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/pu.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/sg.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/sl.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/slPortability.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/sm.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/ssg.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/ssgAux.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/ssgKeyFlier.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/ssgaWaveSystem.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/ssgconf.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/ul.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/include/plib/ulRTTI.h in plib16-devel-1.6.0-6.fc6.i386.rpm and plib-devel-1.8.4-8.fc6.i386.rpm fileconflict for /usr/lib/pkgconfig/libtorrent.pc in libtorrent-devel-0.10.4-1.fc7.i386.rpm and rb_libtorrent-devel-0.11-5.fc7.i386.rpm fileconflict for /usr/share/man/man1/count.1.gz in fish-1.21.12-1.fc6.i386.rpm and html-xml-utils-3.7-4.fc6.i386.rpm fileconflict for /usr/share/man/man8/imapd.8.gz in uw-imap-2006h-1.fc7.i386.rpm and cyrus-imapd-2.3.8-3.fc7.i386.rpm fileconflict for /var/lib/clamav/main.cvd in clamav-data-empty-0.90.2-1.fc7.i386.rpm and clamav-data-0.90.2-1.fc7.i386.rpm fileconflict for /var/spool/news in inn-2.4.3-6.fc6.i386.rpm and leafnode-1.11.5-4.fc7.i386.rpm
regards,
Florian La Roche
On Wed, 23 May 2007 10:16:35 +0200, Florian La Roche wrote:
Here is a list of all fileconflicts in FC-devel for i386. Not all are bugs, but I think it should be worth it to reduce the list a bit:
fileconflict for /var/lib/clamav/main.cvd in clamav-data-empty-0.90.2-1.fc7.i386.rpm and clamav-data-0.90.2-1.fc7.i386.rpm
How do you find this? (I've not verified it with my owner checker, but) in clamav-data-empty package the file is just a %ghost
fileconflict for /var/spool/news in inn-2.4.3-6.fc6.i386.rpm and leafnode-1.11.5-4.fc7.i386.rpm
This looks interesting. A conflict in directory access permissions (755 in inn, 4755 in leafnode).
inn and leafnode are both news servers and, at run-time, cannot co-exist without additional customisations by a freaky admin. Asking FESCo to permit adding a "Conflicts" if the dir conflict cannot be resolved, would sound plausible.
Thorsten Leemhuis <fedora <at> leemhuis.info> writes:
There were some *discussion* about Fedora making a more strict releases cycle somewhat aligned to the Gnome release cycle. There was afaik no outcome from those discussions yet, but well, before starting to realize those KDE plans it might be better to see the F8 release schedule first.
Speaking of that schedule, when are we going to know that?
Kevin Kofler
On 5/21/07, Kevin Kofler kevin.kofler@chello.at wrote:
Last week, I have prepared a draft document detailing how to go on with KDE 4 in Fedora as I see it: http://fedoraproject.org/wiki/KevinKofler/F8KDE4Plan
This has already gotten some quick looks and positive reactions at last week's KDE SIG meeting. However, not all interested parties were present. Now that the CVS devel branch has unfrozen for Fedora 8, I think it's time to subject this to broader discussion.
Once a plan is agreed on, we need to put the result (something like this document, probably this document with some edits) into a more official namespace on the wiki.
Kevin Kofler
Might be a good time to remind everyone of this draft proposal for KDE apps: http://fedoraproject.org/wiki/PackagingDrafts/KDELooks