gstreamer* ports all have the same UNIQUENAME and OPTIONSFILE ??

Doug Barton dougb at
Wed Jul 4 08:06:21 UTC 2012

Hash: SHA256

On 07/04/2012 00:41, Alfred Bartsch wrote:
> Am 04.07.2012 01:43, schrieb Doug Barton:
>> Howdy,
>> Trying to track down a bug reported by a portmaster user I've
>> noticed that all of the gstreamer* ports that I've checked so far
>> all have the same UNIQUENAME, and thus, the same OPTIONSFILE.
>> AFAICS gstreamer-plugins-all is the only port that sets OPTIONS, so
>> in that sense it's not an issue.
>> However, portmaster uses UNIQUENAME to determine the location to
>> store a file with the distfile info, and the fact that it's the
>> same for every port is creating a conflict. See 
>> for more
>> information about the concept.
>> This problem will theoretically go away if pkgng gets adopted, and
>> I can fix it for portmaster by moving the distfile file into
>> /var/db/pkg where I thought it should have been all along. But I
>> thought I'd mention the UNIQUENAME issue in case it's something
>> that y'all want to address.
>> Doug
> Thank you for pointing this out. There are other ports with shared

... which is a bug, and needs to be fixed for pkgng purposes.

> so I consider it best moving "distfiles" to /var/db/pkg.

I'm in the process of working on that now.

> Then there would be no more messages like "directory not empty" while
> executing "make rmconfig" in a port directory

That was fixed in recently.

> and perhaps portmaster
> would no longer remove stale distfiles which aren't really stale but
> from different installed program versions with similar names.

That's not related to this issue. portmaster does a pattern match on the
distfiles, and does a pretty good job to not delete files that are valid
for any installed port. This issue with the gstreamer* ports sharing
UNIQUENAME has completely buggered that for 'portmaster -d' however.

My goal for a long time has been to get the distfile info into the
official db, and then relax the pattern matching in portmaster since
we'll have a very good idea what the affected port is actually using.
Unfortunately, portmgr has not shared my enthusiasm.


- -- 

    This .signature sanitized for your protection

Version: GnuPG v2.0.19 (FreeBSD)


More information about the freebsd-multimedia mailing list