Re: Gentoo



* Sergei Trofimovich <slyfox 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: weigelt metux de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]