According to https://bugzilla.rpmfusion.org/show_bug.cgi?id=993#c36, I don't see
why alternatives shouldn't do the job. Beside of that, there are IMHO enough other
packages in Fedora using alternatives, but not providing the same functionality,
just similar or partially. That's my two cents - just to provide my perspective as
well. By the way: Mandriva 2010 is still providing freeze with /usr/bin/melt, too.

MLT is a framework that supports closed source or rather "not open source" standards and therefor is not a part of fedora and never will be. I think before changing anything in the fedora repository we should consider that.

Alternatives is not designed for this. http://fedoraproject.org/wiki/Packaging:EnvironmentModules may be okay as it's aimed at programs that end users can change.

I'm not sure that it is a better fit than removing/renaming the /usr/bin/melt file in one of the packages, though.

Replying to [comment:4 underscores]:
Nope, mlt is a true FOSS, it can't be included in fedora because it depends on ffmpeg which may has some patent issues(but debian legals think it's safe to include ffmpeg in their distribution).

MLT and it's deriatives packages(e.g. kdenlive openshot) are well-known and have many users.
See http://fedoraproject.org/wiki/Features/kdenlive

As I mentioned ealier, keeping long obsoletes packages in fedora is always not a good idea because it's agaist fedora objetives, freeze in fedora don't even have an URL now.

http://fedoraproject.org/wiki/Objectives

From my side, both renaming or using altervatives are acceptable, but we still should find some optimal solution from the point of view from end users.

I find it ''a little more'' than mildly annoying that the mlt maintainer wasn't at all contacted about any of this before it hit FESCo... I have to wonder what would happen when this ticket reaches a terminus without my involvement at all; does the rpmfusion equivalent of provenpackager make the change without asking me, too? :(

From my PoV (as someone who uses a lot of "obsolete" packages), packages which have users in Fedora proper should take precedence over third party packages. Yes MLT is FOSS, and probably has more users, but it's not a part of Fedora proper.

I am against renaming the current /usr/bin/melt and /usr/bin/melt-mlt in any current release, without knowing what packages would be affected, both third party and in either rpmfusion or Fedora. I am amenable to changes in rawhide and future releases, though, especially given the fact that even its description lends itself to being rarely used.

From Fedora's end, we have one package which depends on freeze, and none which explicitely require /usr/bin/melt; rsc: do you know of any packages either third party or not, which require freeze's /usr/bin/melt? I'd rather err on the safe side (mlt-melt is already used in kdenlive, and the current openshot review carries a patch to use mlt-melt) to be completely honest, especially in current releases.

(This came up on #fedora-kde, so I'll add my 2 cents.)

Alternatives and Environment Modules are both the completely wrong solution, as those are completely different executables, not alternatives which do the same thing.

I don't see what's wrong with the current solution of renaming mlt's melt, which is already in place.

Another reason to rename the mlt version is that it's primarily designed to be used by GUIs such as Kdenlive or OpenShot, which can easily be adjusted to any executable name, and in fact both have patches in the current RPM Fusion packaging (kdenlive is already in RPM Fusion with such a patch, OpenShot's review request also has such a patch), whereas freeze's melt is a command-line utility to be used directly.

The current setup is as it is for a reason.

Replying to [comment:7 rrix]:

I find it ''a little more'' than mildly annoying that the mlt maintainer wasn't at all contacted about any of this before it hit FESCo... I have to wonder what would happen when this ticket reaches a terminus without my involvement at all; does the rpmfusion equivalent of provenpackager make the change without asking me, too? :(

From my PoV (as someone who uses a lot of "obsolete" packages), packages which have users in Fedora proper should take precedence over third party packages. Yes MLT is FOSS, and probably has more users, but it's not a part of Fedora proper.

I am against renaming the current /usr/bin/melt and /usr/bin/melt-mlt in any current release, without knowing what packages would be affected, both third party and in either rpmfusion or Fedora. I am amenable to changes in rawhide and future releases, though, especially given the fact that even its description lends itself to being rarely used.

From Fedora's end, we have one package which depends on freeze, and none which explicitely require /usr/bin/melt; rsc: do you know of any packages either third party or not, which require freeze's /usr/bin/melt? I'd rather err on the safe side (mlt-melt is already used in kdenlive, and the current openshot review carries a patch to use mlt-melt) to be completely honest, especially in current releases.

To biuld in kkofler's comment, I am maintainer of both kdenlive and mlt, so I can easily react to issues in the naming of dependencies in kdenlive.

Replying to [comment:6 supercyper]:

As I mentioned ealier, keeping long obsoletes packages in fedora is always not a good idea because it's agaist fedora objetives

I fail to see the objective you refer to. Please be a little more specific to why packages that are 'old' although 'stable' should not be included in the distribution.

Replying to [comment:9 kkofler]:

Another reason to rename the mlt version is that it's primarily designed to be used by GUIs such as Kdenlive or OpenShot, which can easily be adjusted to any executable name, and in fact both have patches in the current RPM Fusion packaging (kdenlive is already in RPM Fusion with such a patch, OpenShot's review request also has such a patch), whereas freeze's melt is a command-line utility to be used directly.

The current setup is as it is for a reason.

The main reason why I think renaming melt in freeze will be a better solution is melt in freeze is actually a symlink to /usr/bin/freeze and uers can also use another symlink unfreeze instead of melt.

melt in mlt is useful, upstream and other linux distribution both call it melt.

http://mltframework.org/twiki/bin/view/MLT/MltMelt

Replying to [comment:7 rrix]:

I find it ''a little more'' than mildly annoying that the mlt maintainer wasn't at all contacted about any of this before it hit FESCo... I have to wonder what would happen when this ticket reaches a terminus without my involvement at all; does the rpmfusion equivalent of provenpackager make the change without asking me, too? :(

Sorry for this, I'm not aware that the maintainer of mlt is changed.

From my PoV (as someone who uses a lot of "obsolete" packages), packages which have users in Fedora proper should take precedence over third party packages. Yes MLT is FOSS, and probably has more users, but it's not a part of Fedora proper.
freeze has very few users as I realized(many better alternatives gzip bzip2 xz etc), so I don't think it should have precedence over mlt.

Replying to [comment:12 gbraad]:

I fail to see the objective you refer to. Please be a little more specific to why packages that are 'old' although 'stable' should not be included in the distribution.

freeze is actually very old(dead since 1999) and deprecated by GNU zip suite for a long time, although I'm not against to include it in the repo, but it will be better to let it have a low priority.

See http://www.qnx.com/developers/docs/6.4.1/neutrino/utilities/f/freeze.html

Replying to [comment:8 kkofler]:

(This came up on #fedora-kde, so I'll add my 2 cents.)

Alternatives and Environment Modules are both the completely wrong solution, as those are completely different executables, not alternatives which do the same thing.

I don't see what's wrong with the current solution of renaming mlt's melt, which is already in place.
Not wrong/issues for current solution :), but I don't think the current solution is the optimal.

1. melt is the only executable in mlt, but melt in freeze is a symlink to freeze, users can use freeze -d or unfreeze instead
2. melt in mlt is well-documented and has more users, but melt has very few docs in the internet.
3. mlt is still under active development, but freeze is dead and deprecated for more than 10 years
4. Debian/gentoo/arch use melt in mlt
5. At least two packages requires melt in mlt, but only amavisd-new depends on freeze(also freeze along with many other deps in amavisd-new are optinal deps)

Before renaming a binary, actually we need to contact upstream first to persuade them to rename their binaries to avoid conflict.
But it's hard to do so for mlt, because freeze don't even have a official/formal webpage/URL.

Replying to [comment:11 rrix]:

To biuld in kkofler's comment, I am maintainer of both kdenlive and mlt, so I can easily react to issues in the naming of dependencies in kdenlive.
Maybe I'm a bit rude for not contacting you before submit a ticket in Fesco, but I think renaming melt in mlt is definitely not a good idea, too many packages depends on it, renaming this binary confuses a lot for end users and other packagers.
See
http://www.mltframework.org/twiki/bin/view/MLT/Projects

Some notes about this file conflict:
The original File conflict about /usr/bin/melt is reported by Michael Schwendt.

Then, the original maintainer reported this conflict to upstream, but upstream don't rename melt to another name because /usr/bin/melt is not found in Debian/Ubuntu and Arch Linux repositories. But upstream add a configure option --rename-melt=foo for fedora.

See https://bugzilla.rpmfusion.org/show_bug.cgi?id=662

But programs which depend on mlt still use melt as command line name, this caused to some bugs in kdenlive in the past.

See https://bugzilla.rpmfusion.org/show_bug.cgi?id=880
https://bugzilla.rpmfusion.org/show_bug.cgi?id=863

From my point of view, even using Conflict field in mlt as Michael Schwendt suggested will be better than renaming it to mlt-melt.

Because Debian/Ubuntu/Arch/Gentoo/Mandriva continue to use melt in their packages, upstream still use melt in their documents. Programs (Openshot Kdenlive) which depends on mlt continue to require /usr/bin/melt.

Normally we should rename conflict file in either packages, but I think this is a special case:
1.freeze is dead since 1999, thus we can't persuade freeze author to rename melt to another name.
2.melt in mlt is well-documented and also widely used, most linux distributions don't have freeze in their repos and won't solve this file conflicts, renaming lead to a divergence between Fedora and the other world.

Replying to [comment:7 rrix]:

rsc: do you know of any packages either third party or not, which require
freeze's /usr/bin/melt? I'd rather err on the safe side (mlt-melt is already
used in kdenlive, and the current openshot review carries a patch to use
mlt-melt) to be completely honest, especially in current releases.

I don't recall their names out of the box, but there's a bunch of proprietary
third-party packages out there depending on /usr/bin/melt from freeze, yes.

Replying to [comment:16 supercyper]:

Before renaming a binary, actually we need to contact upstream first to persuade
them to rename their binaries to avoid conflict.
But it's hard to do so for mlt, because freeze don't even have a official/formal
webpage/URL.

Why would it be hard to contact freeze upstream? Tom did that some time ago, see:
http://cvs.fedoraproject.org/viewvc/rpms/freeze/devel/Freeze_license_email.txt

Personally I would love to see folks involved here talk and come to some way forward and ONLY when that fails talk to fesco, but will add it to the next meeting for discussion.

Replying to [comment:20 kevin]:

Personally I would love to see folks involved here talk and come to some way forward and ONLY when that fails talk to fesco, but will add it to the next meeting for discussion.

Unfortunately, I will be on a bus somewhere in Sweden during next week's FESCo meeting.

I see no reason to change things at the current time:
All packages which depend on mlt's melt carry patches to use /urs/bin/mlt-melt
It should be possible to carry patches for other, new, packages, or re-evaluate when they come up.
Unspecified 3rd party proprietary packages depend on freeze's /usr/bin/melt in EPEL, which I think that we have some responsibility to keep working, even if they are 3rd party proprietary packages.
mlt's melt is used only by other packages, rarely called by the end user
* freeze's melt is used by users mostly

Grr, stupid wiki formatting, sorry folks.

Replying to [comment:21 rrix]:

Replying to [comment:20 kevin]:

Personally I would love to see folks involved here talk and come to some way forward and ONLY when that fails talk to fesco, but will add it to the next meeting for discussion.

Unfortunately, I will be on a bus somewhere in Sweden during next week's FESCo meeting.

I see no reason to change things at the current time:
All packages which depend on mlt's melt carry patches to use /urs/bin/mlt-melt
It should be possible to carry patches for other, new, packages, or re-evaluate when they come up.
* Unspecified 3rd party proprietary packages depend on freeze's /usr/bin/melt in EPEL, which I think that we have some responsibility to keep working, even if they are 3rd party proprietary packages.

Need more evidence on this one, I don't think current proprietary softwares still use a such old packages. I can't find anything about this on internet. Also, we also need some evidence that those 3rd packages is calling /usr/bin/melt instead of /usr/bin/freeze.

But mlt is really used by C4IP Orion SD - a Proprietary SDI - based broadcast playout server.

Also, we are talking things on fedora, no one intends to change this on EPEL4/5.

We should keep consistence with upstream and other distributions.

More notes for amavisd-new - the only package in the repo which requires freeze:

This package call unfreeze first, then freeze -d, so it's very safe to remove melt symlink from freeze

See ./amavisd.conf: ['F', \&do_uncompress, ['unfreeze','freeze -d','melt','fcat'] ],

Since amavisd-new is a Email filter with virus scanner support, it's also safe to remove freeze support from this package, because nearly no Windows users still use .F format instead .7z/.zip/.rar/.tar.gz/.tar.bz2

So I suggest if no alive 3rd packages call /usr/bin/melt in freeze directly, we can simply remove melt symlink in freeze.
If there are a bunch of 3rd packages still use melt, then we can consider using Conflicts in both mlt and freeze, but currently I found nothing on Google on this.

Note:
Using mlt-melt instead melt in kdenlive and openshot is a hack rather than a patch, those patches hacked .py files, there are also some other mlt-related programs call melt.
See https://bugzilla.rpmfusion.org/attachment.cgi?id=433&action=diff

Replying to [comment:24 supercyper]

Note:
Using mlt-melt instead melt in kdenlive and openshot is a hack rather than a patch, those patches hacked .py files, there are also some other mlt-related programs call melt.
See https://bugzilla.rpmfusion.org/attachment.cgi?id=433&action=diff

Uh, no, that's a patch, there's nothing hacky at all about it.

Leaving my opinion here, since I am going to miss fesco today, probably:

I don't think we can really guarantee no conflicts between repos. Considering that freeze is really obsolescent, and probably used by very few people, I would personally consider it sufficient to add an explicit Conflicts: to one or both of these packages, and be done with it.

FESCo feels this is not something we can/should weigh in on. Please work it out between maintainers.