Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
On Thu, Oct 11, 2012 at 8:22 PM, Mike Frysinger wrote: > On Thursday 11 October 2012 14:56:11 Ben Kohler wrote: >> I would like to suggest that the "server" profile variants >> (ie default/linux/amd64/10.0/server) be unlisted from profiles.desc, so >> that they do not show up in "eselect profile list" for new users. As far >> as I know, this server target is unmaintained, undesirable, and somewhat >> silly, if you look at its make.defaults. If this target is being kept >> around just so we don't break older setups, then simply removing from >> profiles.desc would allow these systems to keep using the profile, without >> presenting it as a viable option for new users. > > sounds like something to fix rather than punt. i don't know why you think > having server profiles is "undesirable", but i certainly desire it on many > systems. like servers. the desktop and developer profiles are not > appropriate. > -mike +1. I want these profiles to *staty*. I am using this profile on my "home boxes". It is the most minimal profile as the rest of the profiles pull in too much useless stuff. What is wrong with these profiles anyway? -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
On Thu, Oct 11, 2012 at 9:04 PM, Walter Dnes wrote: > On Thu, Oct 11, 2012 at 03:22:17PM -0400, Mike Frysinger wrote > >> sounds like something to fix rather than punt. i don't know why >> you think having server profiles is "undesirable", but i certainly >> desire it on many systems. like servers. the desktop and developer >> profiles are not appropriate. > > If it's going to be kept around, then please get rid of the warning in > ebuilds. I'm one of the few people who checks /var/log/portage/elog > regularly. The server profile is useless because it pollutes > /var/log/portage/elog with a warning that this profile is unmaintained... > ***ONCE FOR EVERY LAST SINGLE PACKAGE YOU BUILD***. If you want a light > profile, I suggest doing what I do... start your USE variable in > make.conf with "-*", and add any flags you need, either in package.use or > in make.conf. > > -- > Walter Dnes > I don't run "desktop environments"; I run useful applications > We can remove the warning. There is nothing really wrong with these profiles. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
On Fri, Oct 12, 2012 at 4:08 AM, Markos Chandras wrote: > +1. I want these profiles to *staty*. I am using this profile on my > "home boxes". It is the most minimal profile as the rest of the > profiles pull in too much useless stuff. What is wrong with these > profiles anyway? Looking at the actual profiles themselves, using server vs the base profile makes these changes: USE="-perl -python snmp truetype xml" So, you're getting less perl/python support, but you're getting snmp, truetype, and xml. I think overall you'd get a more minimal setup with the base profile, and if you really want -perl/-python you could just set those in your USE. I'd think that your home box would be more likely to benefit from perl/python support on packages than having snmp support. But, to each his own... I'd be all for there being an actual minimal profile, but I don't think server really is that. Rich
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
On Fri, Oct 12, 2012 at 9:18 AM, Rich Freeman wrote: > On Fri, Oct 12, 2012 at 4:08 AM, Markos Chandras wrote: >> +1. I want these profiles to *staty*. I am using this profile on my >> "home boxes". It is the most minimal profile as the rest of the >> profiles pull in too much useless stuff. What is wrong with these >> profiles anyway? > > Looking at the actual profiles themselves, using server vs the base > profile makes these changes: > USE="-perl -python snmp truetype xml" > > So, you're getting less perl/python support, but you're getting snmp, > truetype, and xml. > > I think overall you'd get a more minimal setup with the base profile, > and if you really want -perl/-python you could just set those in your > USE. I'd think that your home box would be more likely to benefit > from perl/python support on packages than having snmp support. But, > to each his own... > > I'd be all for there being an actual minimal profile, but I don't > think server really is that. > > Rich > Removing python and perl support is good enough to justify that this profile is "minimal" ;) Moreover, snmp is something you really want in 24/7 boxes. Anyhow, I see no reason to remove these profiles just because they are 'similar' to the base profile. But I do agree to remove the ewarn message as it a bit annoying if you update such systems often enough. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] [RFC] python-r1 + distutils-r1, v2 (+ comparison)
On Mon, Oct 08, 2012 at 05:16:05PM +0200, Michał Górny wrote:
> Hello,
>
> This is the second and hopefully last version of python-r1 +
> distutils-r1 eclasses before committing. I would also like to shortly
> point out the goals and the differences between various python eclasses
> in Gentoo.
>
> Both are attached. For those who prefer hosted form:
> https://bitbucket.org/mgorny/gx86-working-tree/src/5a2d39e69d6d/gx86/eclass/python-r1.eclass
> https://bitbucket.org/mgorny/gx86-working-tree/src/5a2d39e69d6d/gx86/eclass/distutils-r1.eclass
>
> Changes from the previous version:
> - support for DOCS and HTML_DOCS (alike EAPI 4);
> - minimal support for passing arguments to setup.py (through
> distutils-r1_python_compile & distutils-r1_python_install);
> - EPYTHON values adjusted to match python.eclass;
> - scripts are -${EPYTHON} suffixed -- i.e. foo-python2.7,
> foo-pypy-c1.8;
> - a wrapper script[1] is used to choose the correct script instead of
> constant symlink. Thus, EPYTHON & eselect-python are respected,
> - PYTHON_COMPAT can be an array only.
>
> What still needs considering:
> - a nicer way of passing setup.py arguments (mysetuppyargs=()?,
> esetuppy wrapper?);
> - Prefix support.
>
> [1]:https://bitbucket.org/mgorny/python-exec
>
>
> Now, for the differences part.
>
> Goals
> -
>
> python.eclass aims to support every single Python package out there,
> including rare corner cases supported in-eclass. It supports both
> packages supporting one and multiple Python implementations. distutils
> support is provided by second eclass, and both provide phase functions
> (python.eclass providing default ph.f. wrappers).
>
> python-distutils-ng aims to support majority of Python packages using
> distutils. With a bit of hackery it can support non-distutils packages,
> but the use is limited to the common cases. In an uncommon case, it's
> not flexible enough. It supports Python packages supporting multiple
> implementations only.
>
> python-r1 aims mostly to provide tools to support majority of Python
> packages. It tries to be simple & flexible, thus allowing handling
> various corner cases without special branches of code in the eclass.
> It doesn't export any phase functions, nor set dependencies by default
> (just provides a variable with them).
>
> Right now, it supports packages supporting multiple implementations
> only; if necessary, the support will be extended -- either through
> additional code if that wouldn't add too much complexity, or through
> additional eclass.
>
> It is accompanied by distutils-r1 which provides a simple overlay for
> the very common case of distutils packages. This eclass exports phase
> functions and sets dependencies implicitly. It also handles renaming
> the distutils-installed scripts and linking the python-exec wrapper.
>
>
> Python targets
> --
>
> python.eclass uses implicit Python target specifications. It provides
> no ebuild-transparent way of enabling/disabling them.
>
> python-distutils-ng and python-r1 use USE flags to explicitly list
> enabled Python implementations. Both eclasses use the same values for
> PYTHON_TARGETS USE_EXPAND.
>
>
> Installed scripts
> -
>
> python-distutils-ng rework the installed scripts creating copies for
> Python implementations and changing the shebang. The created copies
> don't differ any other way. The old script name is then symlinked to
> the version for default implementation.
>
> python.eclass & python-r1 instead let distutils rework the scripts
> and just rename them before merging. A wrapper is used to choose
> the correct version, respecting EPYTHON & eselect-python.
>
> python.eclass installs the files to separate installation images
> and merges them. python-r1 installs them to the main image directly,
> renaming the installed scripts between successive implementations.
>
> python.eclass creates a wrapper script for each package. The script is
> written in python. python-r1 instead installs the compiled wrapper
> once (in an ebuild), and symlinks it for the packages. The wrapper is
> written in much simpler C.
>
> The implementation suffixes for all three eclasses are different:
> - python.eclass uses -2.6, -2.7 for Python, -2.7-pypy-1.8,
> -2.7-pypy-1.9 for pypy and -2.5-jython for jython (enjoy!);
> - p-d-ng uses Python target names (-python2_6, -python2_7, -pypy1_8),
> - p-r1 uses $EPYTHON values (-python2.6, -python2.7, -pypy-c1.8 (sic!)).
>
>
> Dependency on Python
>
>
> python.eclass has a few variables necessary to set dependencies
> on Python implementation, including internal sub-syntax (and an even
> more complete generator sub-syntax in progress overlay). I suspect that
> most of the possible variants can be achieved using it, just please
> don't make me try learning it all.
>
> Additionally, packages supporting multiple Python implementations are
> required to specify their supported Python versions twice -- with
> P
[gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages.
From time to time the topic of deprecating EAPIs comes up and usually one suggestion is to keep 0 and start with converting EAPI 1 ebuilds. Then someone comes along and asks what is the point? Indeed, a fair question. The following tries to take a different approach to the topic. It's not all thought through in detail, but that wont happen anytime soon, after all it's on my TODO for long enough. So I present it in the hope others will try to poke holes into it or even pick it up. EAPI=0 requirement pointless? - The EAPI=0 requirement comes from having to provide an update path for systems with a package manager without EAPI support. By now we are talking about really ancient systems and it's questionable if there is any merit in supporting such. Further the situation is that some of the maintainers of must be EAPI 0 ebuilds already moved on as the majority of users will profit from a bump. As a result the clean upgrade path is already borked and the value of keeping others at EAPI=0 deteriorates further and further. Forcing EAPI 0 on some maintainers for all eternity doesn't strike me as brilliant, quite the opposite frankly. After all new EAPIs are supposed to contain bug fixes and new features required to write better ebuilds. If all installed PMs supported EAPI? The issue of an update path is reduced to keeping intermediate versions in tree. Those PMs also support EAPI=1, rendering EAPI=0 obsolete. Base EAPI - Systems without having a package manager installed that supports at least the 'Base EAPI' aren't considered supported any longer. Maintainers of system packages can use the Base EAPI without worrying. Maintainers of system packages can use more recent EAPIs but need to take special care. Value of Base EAPI -- Maintainers of system packages need to be able to use newer EAPIs after some time. They can wait but not forever. built_with_use removal is one example, strong vs weak blockers an other. The value can be based on time ( i.e. after 3 years ) or set by council decision. A combination is fine as well. The value should be kept low enough so the rule "maintainers don't have to care about using it" holds. The need of derived distributions / package managers should be considered, ie. let them catch up if necessary. Security updates should be possible for some time without full updates. This extends to other packages as well. So maintainers of critical non system packages can use this EAPI as well if they want. Guess EAPI=2 would be a reasonable compromiss. Deprecation? EAPIs below the base EAPI can be considered deprecated if one desires. References in devmanual can be removed and so the document be simplified. Once there are only few ebuild of a deprecated EAPI left, it might make sense to convert them and add a repoman check so the number of used EAPIs is kept reasonable. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [PATCH/RFC] eclass/flag-o-matic.eclass: prepend-ldpath
On 10/11/2012 2:40 PM, Marien Zwart wrote:
I'm going to do something potentially rude and comment on this without
having read the entire thread.
On Thu, Oct 11, 2012 at 10:39 PM, Gregory M. Turner wrote:
Anyhow one thing I have figured out is how things can work correctly on
Linux wihtout -L.: on Linux, the python plugins aren't actually linked
against libpython.so!
Python can be built with and without a shared library
(libpythonx.y.so). If the shared library is built the interpreter
executable is linked against it (of course), and normally so are the
extension modules. This is useful because it makes the linker do the
right thing for applications that embed python (and end up loading
libpythonx.y via dlopen). If the shared library is not built extension
modules cannot link against it, and the python executable itself
exports the relevant symbols. So on a normal shared python build
extensions should end up linked against libpythonx.y.so.
However, at least one popular distro and presumably most of its
derivatives (Debian) has a system python built without the shared
library, plus the shared library built separately, for use by
applications that embed python. I am not entirely sure why they still
do this (if I understand correctly it was originally done for
performance reasons, but I'm not sure if they've checked those are
still valid). Their extension modules cannot link to libpythonx.y:
their python interpreter executable provides the same symbols
libpythonx.y provides, so loading such an extension module into the
regular interpreter would result in collisions.
The reason I mention this is Gentoo's python is built with the shared
library, so on Gentoo your extensions *should* end up linked to
libpythonx.y (if they use a more or less standard build system, at
least). If yours are not I'm curious what happened, and would
appreciate it if you gave me some more information off-list (marienz
on freenode or email).
Thanks a ton for this info, that explains a lot. Actually, got this
notion testing outside of Gentoo, building from a vanilla python 3.3.0
tarball on a Fedora box. I wanted to see what happens in a completely
"Gentoo-free" environment so as to get some kind of baseline
understanding of how upstream is propagating stuff through the Makefiles
to setup.py.
Probably, I screwed up ./configure (I tried to approximate Gentoo's
arguments), and requested a non-shlib build. Guess it would have been
clearer if I'd mentioned that in my post -- sorry if I worried you :)
I do, of course, intend to try it on my main Gentoo ~amd64 -- if I ever
see it fail to do as you describe, I'll let you know, Marien.
My i686 prefix is up to date and I can confirm that it is linking
against libpython there.
But... wow. In my almost-vanilla i686 cross-prefix (hosted by my
only-moderately-rice multilib ~amd64 workstation), in
=dev-lang/python-2.7.3-r2, the modules are linked like so:
i686-pc-linux-gnu-gcc -pthread -shared -Wl,-O1 \
-L${EPREFIX}/lib -L${EPREFIX}/usr/lib \
-L/usr/lib32 -L/usr/lib64 -L/lib32 -L/lib64 \
-L. \
-Wl,-O1 \
-L${EPREFIX}/lib -L${EPREFIX}/usr/lib \
-L/usr/lib32 -L/usr/lib64 -L/lib32 -L/lib64 \
-L. \
-fno-strict-aliasing \
-O2 -march=i686 -pipe -m32 \
-fwrapv -DNDEBUG \
-I. -IInclude -I./Include \
-I${EPREFIX}/usr/include \
build/temp.linux-i686-2.7${EPREFIX}/var/tmp/portage/dev-lang/python-2.7.3-r2/work/Python-2.7.3/Modules/mathmodule.o
\
build/temp.linux-i686-2.7${EPREFIX}/var/tmp/portage/dev-lang/python-2.7.3-r2/work/Python-2.7.3/Modules/_math.o
\
-L${EPREFIX}/lib -L${EPREFIX}/usr/lib \
-L/usr/lib32 -L/usr/lib64 -L/lib32 -L/lib64 \
-L. \
-lm -lpython2.7 \
-o build/lib.linux-i686-2.7/math.so
Which is just shameful. In this case, I'm pretty sure all those
-L{${EPREFIX},}{/usr,}/$(libdir) clauses are not coming from me:
[PREFIX] $ emerge --info --verbose | grep /lib
sys-devel/libtool:2.4.2::gentoo_prefix
COLLISION_IGNORE="/lib/modules/* *.py[co]"
PKG_CONFIG_PATH="${EPREFIX}/usr/lib/pkgconfig:$( :;
)${EPREFIX}/usr/share/pkgconfig"
PORTAGE_BIN_PATH="${EPREFIX}/usr/lib/portage/bin"
PORTAGE_PYM_PATH="${EPREFIX}/usr/lib/portage/pym"
UNINSTALL_IGNORE="/lib/modules/*"
(snippets edited for readability obv).
Regarding the gcc-as-linker invocation above:
First, something puts in all kinds of inappropriate amd64 multilib paths
(this ends up being harmless as wrong-arch libraries get rejected at
link-time and treated as non-matches for -lclauses... still, WTF?).
Secondly, something puts the built-in ld search paths into the
command-line ld search path (a practice which has been roundly
disparaged in this thread, and correctly so, IMO).
Thirdly, prefix x86-linux also clearly suffers from the original problem
I was seeing in cygwin, and which inspired this thread (putting -L.
a
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
On 10/11/2012 3:31 PM, Ben Kohler wrote: There are other ways to achieve a "lighter" system, but that's not really what this is about. The server profiles are not any lighter than the base profiles. To those in favor of keeping some kind of "server" profile around, how would it differ from the base profile? What would you enable or disable on top of the base? I am pretty sure that the current USE="-perl -python snmp truetype xml" is not what any of you would suggest. In my opinion, removing /usr/portage/profiles/targets/server/make.defaults and having the "server" target apply nothing over the base profiles, and then dropping the warning from the server profiles, would be a better situation than where we are now. -Ben That seems pretty reasonable. Another possibility, I suppose, would be to combine Rich's idea with yours and get: base -> minimal -> server (noop) Also super-easy if we just build the above cascade, take what's in server, move it into minimal, git rid of the awful warning, and call it fixed. At least by clarifying what is meant by "server", we might inspire someone to contribute more enhancements later. Kind of the opposite of your original proposal, Ben :P At least we've established broad consensus that the warning should be silenced. -gmt
Re: [gentoo-dev] [RFC] python-r1 + distutils-r1, v2 (+ comparison)
On Fri, 12 Oct 2012 13:35:44 +0300
Reinis Danne wrote:
> On Mon, Oct 08, 2012 at 05:16:05PM +0200, Michał Górny wrote:
> > Hello,
> >
> > This is the second and hopefully last version of python-r1 +
> > distutils-r1 eclasses before committing. I would also like to shortly
> > point out the goals and the differences between various python eclasses
> > in Gentoo.
> >
> > Both are attached. For those who prefer hosted form:
> > https://bitbucket.org/mgorny/gx86-working-tree/src/5a2d39e69d6d/gx86/eclass/python-r1.eclass
> > https://bitbucket.org/mgorny/gx86-working-tree/src/5a2d39e69d6d/gx86/eclass/distutils-r1.eclass
> >
> > Changes from the previous version:
> > - support for DOCS and HTML_DOCS (alike EAPI 4);
> > - minimal support for passing arguments to setup.py (through
> > distutils-r1_python_compile & distutils-r1_python_install);
> > - EPYTHON values adjusted to match python.eclass;
> > - scripts are -${EPYTHON} suffixed -- i.e. foo-python2.7,
> > foo-pypy-c1.8;
> > - a wrapper script[1] is used to choose the correct script instead of
> > constant symlink. Thus, EPYTHON & eselect-python are respected,
> > - PYTHON_COMPAT can be an array only.
> >
> > What still needs considering:
> > - a nicer way of passing setup.py arguments (mysetuppyargs=()?,
> > esetuppy wrapper?);
> > - Prefix support.
> >
> > [1]:https://bitbucket.org/mgorny/python-exec
> >
> >
> > Now, for the differences part.
> >
> > Goals
> > -
> >
> > python.eclass aims to support every single Python package out there,
> > including rare corner cases supported in-eclass. It supports both
> > packages supporting one and multiple Python implementations. distutils
> > support is provided by second eclass, and both provide phase functions
> > (python.eclass providing default ph.f. wrappers).
> >
> > python-distutils-ng aims to support majority of Python packages using
> > distutils. With a bit of hackery it can support non-distutils packages,
> > but the use is limited to the common cases. In an uncommon case, it's
> > not flexible enough. It supports Python packages supporting multiple
> > implementations only.
> >
> > python-r1 aims mostly to provide tools to support majority of Python
> > packages. It tries to be simple & flexible, thus allowing handling
> > various corner cases without special branches of code in the eclass.
> > It doesn't export any phase functions, nor set dependencies by default
> > (just provides a variable with them).
> >
> > Right now, it supports packages supporting multiple implementations
> > only; if necessary, the support will be extended -- either through
> > additional code if that wouldn't add too much complexity, or through
> > additional eclass.
> >
> > It is accompanied by distutils-r1 which provides a simple overlay for
> > the very common case of distutils packages. This eclass exports phase
> > functions and sets dependencies implicitly. It also handles renaming
> > the distutils-installed scripts and linking the python-exec wrapper.
> >
> >
> > Python targets
> > --
> >
> > python.eclass uses implicit Python target specifications. It provides
> > no ebuild-transparent way of enabling/disabling them.
> >
> > python-distutils-ng and python-r1 use USE flags to explicitly list
> > enabled Python implementations. Both eclasses use the same values for
> > PYTHON_TARGETS USE_EXPAND.
> >
> >
> > Installed scripts
> > -
> >
> > python-distutils-ng rework the installed scripts creating copies for
> > Python implementations and changing the shebang. The created copies
> > don't differ any other way. The old script name is then symlinked to
> > the version for default implementation.
> >
> > python.eclass & python-r1 instead let distutils rework the scripts
> > and just rename them before merging. A wrapper is used to choose
> > the correct version, respecting EPYTHON & eselect-python.
> >
> > python.eclass installs the files to separate installation images
> > and merges them. python-r1 installs them to the main image directly,
> > renaming the installed scripts between successive implementations.
> >
> > python.eclass creates a wrapper script for each package. The script is
> > written in python. python-r1 instead installs the compiled wrapper
> > once (in an ebuild), and symlinks it for the packages. The wrapper is
> > written in much simpler C.
> >
> > The implementation suffixes for all three eclasses are different:
> > - python.eclass uses -2.6, -2.7 for Python, -2.7-pypy-1.8,
> > -2.7-pypy-1.9 for pypy and -2.5-jython for jython (enjoy!);
> > - p-d-ng uses Python target names (-python2_6, -python2_7, -pypy1_8),
> > - p-r1 uses $EPYTHON values (-python2.6, -python2.7, -pypy-c1.8 (sic!)).
> >
> >
> > Dependency on Python
> >
> >
> > python.eclass has a few variables necessary to set dependencies
> > on Python implementation, including internal sub-syntax (and an even
> > more complete generator sub-syntax in progress o
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
11.10.2012 23:22, Mike Frysinger wrote: > On Thursday 11 October 2012 14:56:11 Ben Kohler wrote: >> I would like to suggest that the "server" profile variants >> (ie default/linux/amd64/10.0/server) be unlisted from profiles.desc, so >> that they do not show up in "eselect profile list" for new users. As far >> as I know, this server target is unmaintained, undesirable, and somewhat >> silly, if you look at its make.defaults. If this target is being kept >> around just so we don't break older setups, then simply removing from >> profiles.desc would allow these systems to keep using the profile, without >> presenting it as a viable option for new users. > sounds like something to fix rather than punt. i don't know why you think > having server profiles is "undesirable", but i certainly desire it on many > systems. like servers. the desktop and developer profiles are not > appropriate. > -mike Indeed. Hardened server profile does not fit in all cases, some non-hardened server profile should exist, BUT without this warning(if it's usable, of course), and probably with better support. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
On Fri, Oct 12, 2012 at 8:46 AM, Sergey Popov wrote: > Indeed. Hardened server profile does not fit in all cases, some > non-hardened server profile should exist, BUT without this warning(if > it's usable, of course), and probably with better support. Well, support is mainly a matter of people stepping up to make it happen, as with all things. I think that lack of interest in this profile in general is at the heart of the problem. I see no reason to go killing it, but making it useful is a matter of those with an interest getting together and deciding what it should be. Rich
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
On Fri, Oct 12, 2012 at 4:18 AM, Rich Freeman wrote:
> On Fri, Oct 12, 2012 at 4:08 AM, Markos Chandras wrote:
>> +1. I want these profiles to *staty*. I am using this profile on my
>> "home boxes". It is the most minimal profile as the rest of the
>> profiles pull in too much useless stuff. What is wrong with these
>> profiles anyway?
>
> Looking at the actual profiles themselves, using server vs the base
> profile makes these changes:
> USE="-perl -python snmp truetype xml"
>
perl and python have not been enabled in the default/linux profile for
some time now:
RCS file: /var/cvsroot/gentoo-x86/profiles/default/linux/make.defaults,v
revision 1.15
date: 2011-10-05 15:22:13 -0400; author: darkside; state: Exp;
lines: +2 -2; commitid: 2e764e8cae624567;
Remove USE={python,perl} from default profile, as discussed/announced.
Bug 250179
Disabling those flags in the server profile is redundant.
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
This is why I said that the server profile are no lighter than the base.
It's actually the base PLUS "snmp truetype xml".
My original suggestion of hiding or removing the server profiles was based
on the assumption that no one wants to maintain it. The server profiles
*in their current state* are silly & undesirable, in my view. The server
target has not been touched in almost 2 years, and most of the people using
it are doing so based on false assumptions.
If it is to remain in its current state, I think it should at least be
removed from the .desc listing. If we have a plan to make the server
profiles useful again, as a purposeful set of flags applied against the
base, then keeping these profiles listed is great. I would use a server
profile myself, in such case.
-Ben
On Fri, Oct 12, 2012 at 8:53 AM, Mike Gilbert wrote:
> On Fri, Oct 12, 2012 at 4:18 AM, Rich Freeman wrote:
> > On Fri, Oct 12, 2012 at 4:08 AM, Markos Chandras
> wrote:
> >> +1. I want these profiles to *staty*. I am using this profile on my
> >> "home boxes". It is the most minimal profile as the rest of the
> >> profiles pull in too much useless stuff. What is wrong with these
> >> profiles anyway?
> >
> > Looking at the actual profiles themselves, using server vs the base
> > profile makes these changes:
> > USE="-perl -python snmp truetype xml"
> >
>
> perl and python have not been enabled in the default/linux profile for
> some time now:
>
> RCS file: /var/cvsroot/gentoo-x86/profiles/default/linux/make.defaults,v
>
> revision 1.15
> date: 2011-10-05 15:22:13 -0400; author: darkside; state: Exp;
> lines: +2 -2; commitid: 2e764e8cae624567;
> Remove USE={python,perl} from default profile, as discussed/announced.
> Bug 250179
>
> Disabling those flags in the server profile is redundant.
>
>
Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc
Markos Chandras schrieb am 12.10.2012 10:08:
>
> +1. I want these profiles to *staty*. I am using this profile on my
> "home boxes". It is the most minimal profile as the rest of the
> profiles pull in too much useless stuff. What is wrong with these
> profiles anyway?
>
If you want a minimal profile you don't need the server profile.
"ln -s ${PORTDIR}/profiles/default/linux/${ARCH}/10.0 make.profile"
gives you a minimal profile.
--
Regards
Daniel
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages.
On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote > From time to time the topic of deprecating EAPIs comes up and usually > one suggestion is to keep 0 and start with converting EAPI 1 ebuilds. > Then someone comes along and asks what is the point? Indeed, a fair > question. It's my understanding that higher EAPI levels include more features. How backwards compatable are the EAPI levels? I.e. assume that we take an ebuild with EAPI 0, and slap in EAPI=1 (or 2 or 3, etc) at the top, without any other changes. Are there any circumstances where the ebuild would behave differently and/or break? The current default, if EAPI is not specified, is EAPI 0. What I'm getting at is... can we safely tell portage to assume that all ebuilds with no EAPI declaration are EAPI 1 (or 2 or 3, etc)? Or will that break some ebuilds? Actually, if only a small percentage of ebuilds break, then it might not be too much of an effort to fix that small subset. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages.
On Fri, 12 Oct 2012 16:38:06 -0400 "Walter Dnes" wrote: > On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote > > From time to time the topic of deprecating EAPIs comes up and > > usually one suggestion is to keep 0 and start with converting EAPI > > 1 ebuilds. Then someone comes along and asks what is the point? > > Indeed, a fair question. > > It's my understanding that higher EAPI levels include more features. > How backwards compatable are the EAPI levels? I.e. assume that we > take an ebuild with EAPI 0, and slap in EAPI=1 (or 2 or 3, etc) at > the top, without any other changes. Are there any circumstances > where the ebuild would behave differently and/or break? In EAPIs after 1, as well as adding shiny new toys, we've removed various deprecated things, split up phase functions, and made some helpers error on invalid input. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/10/12 04:38 PM, Walter Dnes wrote: > On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote >> From time to time the topic of deprecating EAPIs comes up and >> usually one suggestion is to keep 0 and start with converting >> EAPI 1 ebuilds. Then someone comes along and asks what is the >> point? Indeed, a fair question. > > It's my understanding that higher EAPI levels include more > features. How backwards compatable are the EAPI levels? I.e. > assume that we take an ebuild with EAPI 0, and slap in EAPI=1 (or 2 > or 3, etc) at the top, without any other changes. Are there any > circumstances where the ebuild would behave differently and/or > break? Yes. There is more than just new features that have been added. Some default operations have changed. Eclass behaviour can also be different. I'll let others go into the details, but one of the big changes between EAPIs is the way an unspecified DEPEND or RDEPEND is handled. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlB4gVYACgkQ2ugaI38ACPB45QD+PC6PvspnXdmOhMAEOIDPxh2m 4RDWrTw8t86O+iyKodsA/RdRo1r1Xxc734hXbAwtZlxjC3KcU/mnGQVysvflOdjW =uk9m -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Drop EAPI=0 requirement for system packages.
On Fri, 2012-10-12 at 16:38 -0400, Walter Dnes wrote: > It's my understanding that higher EAPI levels include more features. > How backwards compatable are the EAPI levels? I.e. assume that we take > an ebuild with EAPI 0, and slap in EAPI=1 (or 2 or 3, etc) at the top, > without any other changes. Are there any circumstances where the ebuild > would behave differently and/or break? See http://devmanual.gentoo.org/ebuild-writing/eapi/index.html Updating an ebuild from EAPI0 to EAPI1 without changes should be safe. Updating from EAPI0 to EAPI2 or higher without changes is not safe; at the minimum, econf calls would need to be moved from src_compile to src_configure.
[gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.
On Fri, 12 Oct 2012 12:53:15 +0200 Ralph Sennhauser wrote: > The EAPI=0 requirement comes from having to provide an update path for > systems with a package manager without EAPI support. By now we are > talking about really ancient systems and it's questionable if there is > any merit in supporting such. > > Further the situation is that some of the maintainers of must be EAPI 0 > ebuilds already moved on as the majority of users will profit from a > bump. As a result the clean upgrade path is already borked and the > value of keeping others at EAPI=0 deteriorates further and further. Yeah as soon as python went it was pretty much pointless. I don't see any value in forcing system packages to EAPI 0 anymore. Everything you're saying makes sense to me at least. I'd argue against deprecating EAPI 0 any time soon though. Killing EAPI 1 would be a better idea. -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.
On Fri, 12 Oct 2012 21:10:23 -0600 Ryan Hill wrote: > I'd argue against deprecating EAPI 0 any time soon though. Killing > EAPI 1 would be a better idea. I'm not for forced EAPI bumps anytime soon, but I expect EAPI 0 to be gone from tree in 3-5 years once the EAPI=0 requirement is lifted. Currently we have only 6 official EAPIs which is still manageable to remember the details of each. Though it might be confusing for new developers. Once we are at 20 EAPIs it will be an issue also for seasoned folks. Therefore deprecation is a given, how to go about it is certainly up to discussion. What do you see as an acceptable path here? signature.asc Description: PGP signature
