* Sergei Trofimovich sly...@gentoo.org schrieb:
Latest and greatest ebuilds do not have any patches, as they all are in
upstream. So technically gentoo does not maintain local patches at all
(there is no even single sed call). MC team does all maintenance for them
and issues monthly releases. I find it good enough for such application.
Great. If masking stage gives enough time to make bugfix release,
this should suffice :)
But what about the older releases ? Should we perhaps make hotfix
releases for them ?
Most of time gentoo users report bugs directly upstream and maintainer
gets the solution from git tree if it can't wait next release. But those
cases are too rare to maintain them separately.
Those are the situations I'd like to circument (and for project where
this happens frequently, there's oss-qm ;-)).
BTW: one thing's a bit strange in the ebuilds: there's an dependency
on e2fsprogs @linux. Seems that causes mc to include undelfs support.
Better: have a separate useflags for the optional mc-vfs'es.
It could be a dep on e2fsprogs-libs (which is a system depend and thus
resides on most of gentoo boxes).
ACK, of course.
But my point was about the useflag: better introduce an separate one
instead of automagically switching on kernel_linux.
At this point it would be nice to introduce useflags for the vfs'es.
It has more USE flags, but I find portage's aproach better: it exports
to USEs only the things that matter for general user or have optional
external depends. In particular 'use vfs ||' block looks horrible, and I
don't think vfs use flag makes sense. In theory all VFSes could be
exported to the use flags in a way APACHE2_MODULES, LINGUAS or
INPUT_DEVICES.
Exactly my proposal ;-p
One thing should be kept in mind: The simpler ebuild the easier maintenance.
Simplicity doesnt necessarily depend on amount of distinct useflags.
You can cook-up the patch for latest ebuilds and push it to bugs.gentoo.org.
Yep. Just let me finish up rebasing the mvfs branch to recent master
(and see which of the vfs build fixes already have made it into master),
then I'll look into the ebuild issue.
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
