It's been a long weekend (our National Day).... On Sat, 30 Aug 2003, Jorn A Hansen wrote:
> Wan Tat Chee wrote: > > > > Yes - I've got the same impression. But we might just start by ripping > out Python and a few other heavy (in terms of MBytes) pieces and then > still have a freevo specific runtime bundle with some of the smaller > things. Then maybe later on (if there is any point in doing it) > gradually split things up in their original parts. Any thoughts on this? > Should we strive for having a structure similar to the Debian and Gentoo > packages or is that irrelevant? Another idea would be to rip out things > like python-twisted and then create an RPM with the freevo web-plugin > with dependencies on py-twisted and "freevo-base" (freevo without the > web-plugin) - does that make sense? Hmm. This is beginning to sound like a mini-distro. Not a bad idea in itself, but lots of packages would be confusing as well unless we can separate out the major functionality cleanly. Personally I'd like as few packages as possible to avoid questions of the form "What package(s) do I need for XXXX + YYY + ZZZ, etc." I believe it's best we keep the packages similar to other distros (if possible). > > I guess the part we should be most careful about is the stuff in > /runtime/dll/. The python libs seems less fragile as they get compiled > on the users machine :-) With the current binary release freevo does not > depend so much on which versions are on a users machine. This might blow > up in our faces now with the multitude of RPM based distros and versions > now. In particular if the user has taken his RPMs from different odd > places he/we might run into trouble ;-) That's also a reason why I think > that having most RPMs on the "ATrpms & friends" servers (+ maybe some > stuff @ freevo.sf.net ) might save us some headaches. So maybe we should > start working with the apt-rpm guys on adding stuff to their > repositories. But if we know which apps depend on which libs in /dll/ I > guess we could start taking things apart. Do you think I'm on the right > track with all this? > If we go the APT route we definitely need some place to host the non-standard packages. If the current APT sites are willing to do so it'd simplify matters a lot (since some of the dependencies are identical). > BTW I'm running with the 1.3.4 RPMs + mplayer from the ATrpms repository > right now. Seems to work OK. I'm thinking about what my next step should > be - any suggestions? Should I start by installing Python 2.3 or will > Freevo still be able to run with Python 2.2.2 in the future? > As long as you're using freevo-runtime, there shouldn't be too many issues since mplayer was designed to be user-replaceable. I think the biggest problem would be with Python 2.3. I don't have time to test it out now, but when RH did the Python 1.x -> 2.x transition, they coexisted for a while but named python (1.x) and python2 (2.x). I had to patch every occurence of python invocation in the freevo src tree to python2, else change it to '/usr/bin/env python', and alias python to python2 in the $FREEVODIR/freevo script (it was added to the freevo script in the release 1.x days, check the CVS contrib attic for the folder "TatChee_RPM_specs"). The python.org RPMs name the new version python2.3, so we'll have the same issues. Don't know if the next Redhat release will adopt python 2.3 or not. If you can test it out I'd appreciate it. I don't have time this week :( > > > >Still need to scan through freevo/runtime/package_list.mk for stuff > >that I've missed the first time around. I'm not sure if some of the > >runtime modules are still needed for the next release (e.g. who's using > >swig?) > > > I don't have much clue about the current state of dependencies since > I've just started looking at the freevo code itself. Are there any > people who know this or will it just be hard manual work? > I think the package_list.mk file should have most of the common dependencies, but won't help people with special requirements (Dxr3, etc.) > > > Yes I have also looked at the mythtv-suite .spec - it's a bit special > because as I get it it's only purpose is to bundle up the other > packages. But maybe we would also end up with something similar? > That'd be ideal. > > > Candidate for a freevo-lirc plugin -> python-lirc -> lirc dependency bundle? > Dunno. Is there another way to avoid this dependency maze? I feel that it's better just to put all the optional freevo-plugins into its own package and then set the dependencies accordingly (as many as needed). > > > Candidate for a freevo-web -> py-twisted bundle - or does other parts > depend on this? See above. It's needed only for recording AFAIK. > > > > >python-mx http://dag.wieers.com/home-made/apt/ > > # python-mx-base-2.0.4 > > I just found the mx package on RH 9. It might be the same thing named differently. > >swig ? > > > Think I saw this one in Rawhide or RH9 contrib .... > Ok. Thanks. Swig is a bit of a pain, had trouble getting it installed when I was trying to install gnucash previoulsy. T.C. ---- Wan Tat Chee (Lecturer) School of Computer Science, Univ. of Science Malaysia, 11800 USM, Penang, Malaysia. Rm.625 Ofc Ph: +604 653-3888 x 3617 NRG Lab Admin: +604 659-4757 Rm.601-E Ofc Ph: +604 653-4396 Internet: [EMAIL PROTECTED] Web: http://nrg.cs.usm.my/~tcwan GPG Key : http://nrg.cs.usm.my/~tcwan/tcw_gpg-20030322.asc F'print : DCF2 B9B2 FA4D 1208 AD59 14CA 9A8F F54D B2C4 63C7 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
