On Fri, Mar 19, 2010 at 5:26 AM, Lubos Lunak
On Thursday 18 of March 2010, todd rme wrote:
On Thu, Mar 18, 2010 at 5:30 AM, Lubos Lunak
wrote: ... There is a reason why adding community repositories in Yast fetches a list of those from a 3rd party site and knows nothing else than the URL of that list. Yes, this all sucks. ...
Could doing this be the solution? The program would have a trusted third-party list of file types and associated package repositories that the program would download periodically and check against.
That is very similar to "MP3 support is missing, press Yes to install it from Packman", so as I said, unlikely.
I guess I don't understand why it is okay to do this for the repositories containing the restricted codecs, but not okay for the codecs themselves.
Alternatively, you could provide a program that detects something is missing, and third-party repositories could provide packages that add a list of what they could provide. So when you are missing MP3 support, the software will query the lists provided by the repositories and grab the package that provides that capability. So, for instance, packman could provide a "package-detection-lists" rpm that installs a list of media types it can provide, and the KDE program consults that list (along with similar lists from other repos) when it detects a problem. If multiple repositories provide the same capability, the zypper solver would have to take over.
I don't see how this could solve the problems I described. Repositories already offer a list of packages that they provide, and this list is used when the repository is added e.g. in yast. But before it's added, this information cannot be read, so it doesn't solve anything. The same way we cannot install by default a rpm provided by Packman.
It is useful because it is often not obvious which package contains the codec or file reader necessary to open a given file. This is especially true with video containers, where it might be impossible without opening a metadata editing program to view the contents of the container. The method I describe requires people add the repository, but it is a lot easier than having to open a meta-data editor and then hunt through the repository to find the package you need just to open some random video. I guess it could also be set up to query the repositories listed in the "community repositories" list for their lists of provided codecs, then add those repositories. Or it could just prompt you to add repositories from the community repository list. I'm not sure what would and would not be allowed.
It might even be possible to set up so that when you add a repository it automatically queries the repository for this list and installs it if it is available (updating it along with repository updates if it has changed).
I don't understand this either. When the repository is added in yast, the problem is already basically solved.
The problem of matching a given package to a given file you want to open is not solved unless you know a lot about the files and file formats in question. It is only solved if you know that the rmvb and wmv codecs are in w32codecs-all, for instance. As another example, you need to know a random avi movie trailer you downloaded contains an h263 video stream and aac audio stream, and that you need the x264-72 and faad codecs to play it. Similarly, you need to know which version, and which other software, your media player needs to play it (is it gstreamer based, xine based, phonon based, mplayer based, is x264 pulled by good, good extra, bad, or ugly gstreamer packages, etc). This would eliminate that problem, the OS would know what program or programs it needs to install to play the file and will install them automatically. It is also desktop environment-independent. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org