On Wed, Dec 05, 2012 at 12:15:11AM +0600, Alexandr Shadchin wrote: > On Mon, Dec 03, 2012 at 09:16:48PM -0500, Brad Smith wrote: > > On Fri, Nov 30, 2012 at 11:28:12AM +0000, Stuart Henderson wrote: > > > On 2012/11/30 05:47, Brad Smith wrote: > > > > ----- Original message ----- > > > > > On 2012/11/28 23:14, Brad Smith wrote: > > > > > > On Thu, Nov 29, 2012 at 12:14:33AM +0600, Alexandr Shadchin wrote: > > > > > > > On Mon, Nov 19, 2012 at 11:33:09PM +0600, Alexandr Shadchin wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > This update package deadbeef to the latest release 0.5.6. > > > > > > > > Tested on amd64. > > > > > > > > > > > > > > > > Split package on -main, -gtk2 and -gtk3. > > > > > > > > Please make review this change. > > > > > > > > > > > > > > > > Comments ? OK ? > > > > > > > > > > > > > > > > > > > > > > Fix BUILD_DEPENDS. > > > > > > > > > > > > The gtk2 sub-package should have a @pkgpath marker so upgrading > > > > > > from the older package to the new main + gtk2 package set will > > > > > > have the expected result. > > > > > > > > > > good luck getting that to work ;) > > > > > > > > Am I crazy for expecting that to actually work? I was fairly > > > > certain it would but maybe it is another thing with the pkg tools > > > > that doesn't work. > > > > > > The gtk2 package is named deadbeef-gtk2-0.5.6, so it isn't considered > > > as a replacement for deadbeef-0.5.5, so pkg_add -u doesn't consult the > > > deadbeef-gtk2 package at all to even see the @pkgpath line. > > > > > > One thing that could be done would be to name the -main package > > > something like deadbeef-core-0.5.6, name the -gtk2 package deadbeef-0.5.6, > > > remove @pkgpath in PLIST-main, add @pkgpath in PLIST-gtk2, and add > > > @conflicts > > > as necessary. > > > > Ewww. That's pretty awful. > > > > > More than this would need Quirks.pm to be able to do version comparisons > > > rather than the fast hash lookups, but doing those checks for every > > > updated package will slow down pkg_add -u .. > > > > Or better yet get rid of the nonsense of splitting up the port and > > not having to worry about this stuff at all. > > > > I agree, splitting brings more problems. Update diff.
I see a lot of patches for this port. Have you approached the author about pushing these upstream? Specifically the sndio backend and the patches to remove versioning for the plugins to start off with. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
