Mailinglist Archive: opensuse-kde (246 mails)

[todd rme <toddrme2178@xxxxxxxxx>]

On Fri, Mar 19, 2010 at 5:26 AM, Lubos Lunak <l.lunak@xxxxxxx> wrote:
> On Thursday 18 of March 2010, todd rme wrote:
> > On Thu, Mar 18, 2010 at 5:30 AM, Lubos Lunak <l.lunak@xxxxxxx> 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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kde+help@xxxxxxxxxxxx