Re: [gentoo-dev] Repoman rewrite stage3. Migrate check data to the tree

2016-03-11 Thread Brian Dolbec
On Thu, 10 Mar 2016 18:40:31 -0800
Patrick McLean  wrote:

> On Thu, 10 Mar 2016 18:30:07 -0800
> Brian Dolbec  wrote:
> 
> >  So, where do we place this directory and what rules do we
> > establish about it's modifications?
> > 
> >location? : in the metadata dir alongside the install-qa-check.d
> >directory?  
> 
> That sounds reasonable to me, it is certainly metadata.
> 
> > 
> >name of the directory? : repoman, qa-rules, qa-data,
> > repo-qa-data, ... ideas?  
> 
> Something not project name specific, so nothing about repoman. Perhaps
> something like "repo-checks", my personal vote would be make it a
> directory with the contents being merged (so repo-checks.d maybe?)
> 
> > 
> >data format? : json (my favorite) 
> > compatible with many lanquages/interfaces
> > is flexible to match various data types
> >   ie: dictionaries, lists, strings...
> > is human readable/editable
> > can be validated
> > 
> >xml (PLEASE NO!)
> > 
> >native python file  (too language dependant)
> > 
> >ini style (python configparser compatible) meh :/
> > 
> >other ideas?  
> 
> YAML - like JSON but made to be edited/read by humans (comment support
> is a big feature). Also valid JSON is valid YAML. Also can be
> validated just like JSON can.

OK, I just had a closer look at yaml.  It does look easier for humans
to edit and read.  And seems to have the same data type flexibility.
Maybe not quite as many languages have libs for it.  But I don't think
that is an issue for this data.


I also want to separate the repoman release from the main portage
release.  This will have several advantages.

1) smaller portage install for installs that don't need repoman
capabilities.

2) Repoman can add extra dependencies as needed for things like
pyyaml and xmlschema.  These deps would not be required for the
base portage/emerge code.  Keeping a base install stage3 lighter
and not complicate bootstrapping a stage1, stage2.

3) They can be released indendant of each other as the need for a
new release is desired/required.  While repoman will still be tied
to the portage codebase.  Most of it's code use is via fairly
stable API's.  So only when those API's change will there need to
be a simultaneos release.

-- 
Brian Dolbec 




[gentoo-dev] Last rites: dev-tex/fundus & dev-tex/xymtex

2016-03-11 Thread Michael Palimaka
# Michael Palimaka  (11 Mar 2016)
# Fails to build. Use version included in dev-texlive/texlive-science
instead.
# Masked for removal in 30 days. Bug 573780.
dev-tex/xymtex

# Michael Palimaka  (11 Mar 2016)
# Fails to build. Use version included in dev-texlive/texlive-latexextra
instead.
# Masked for removal in 30 days. Bug 574032.
dev-tex/fundus



[gentoo-dev] MySQL virtuals

2016-03-11 Thread Brian Evans
The MySQL team has two virtuals now for 7 months, virtual/mysql and
virtual/libmysqlclient.

From now on, virtual/mysql is to be used for a local server install,
including embedded servers (libmysqld.so).  virtual/mysql-5.6-r8 begins
to enforce this.

virtual/libmysqlclient is for linking to the client libraries and will
track the library changes in a subslot.  Use this when you only need to
link to libmysqlclient.so and don't necessarily need the server install
to be local.

Please adjust any packages as you see fit while doing maintenance.

Brian Evans
MySQL Lead



signature.asc
Description: OpenPGP digital signature