Re: [gentoo-dev] Unified DEPENDENCIES concept
On Fri, 07 Sep 2012 18:55:10 -0400 Michael Orlitzky mich...@orlitzky.com wrote: I think that dependencies are ultimately not hierarchical Situations like foo? ( bar? ( || ( a ( b c ) ) ) ) do happen, so any new syntax would have to be able to deal with that. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Unified DEPENDENCIES concept
On Fri, 07 Sep 2012 18:55:10 -0400 Michael Orlitzky mich...@orlitzky.com wrote: On 09/07/2012 07:45 AM, Ciaran McCreesh wrote: Since DEPENDENCIES hasn't been written up in a Gentoo-friendly manner, and since the Exherbo documentation doesn't seem to suffice to explain the idea here, here's some more details on the DEPENDENCIES proposal. It seems to me that the problem this solves is just one of ontology. It's analogous to trying to stick files named foo, bar, baz, etc. into directories named depend, rdepend, hdepend, and so on. There are a few well-known ways to organize things in a hierarchy, and which one is most efficient depends on the categories and objects that you have. Given the way that most software is built (see: COMMON_DEPEND), I think DEPENDENCIES would work better than what we're doing now, but it also seems more complex. I think that dependencies are ultimately not hierarchical, and this can force duplication in DEPENDENCIES as well. Has anyone considered tagging the package atoms with a list of dependency types? For example, * foo/bar: ( build run host ) * baz/one: baz? ( build ) * baz/two, baz/three: baz? ( build run ) ... This would eliminate duplication of the objects (package atoms) in favor of duplication of the categories (dependency types). Since the package atoms are what we really care about, I think the tradeoff is beneficial. Maintainers get to express each dependency exactly once. This is nowhere near friendly to a developer... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] doheader function for EAPI 5?
31.08.2012 12:35, Paweł Hajdan, Jr. wrote: I'm somewhat interested. Here's the current code dev-lang/v8 uses to install headers: insinto /usr doins -r include || die Using e.g. doheader include/* is slightly prettier IMHO, but it's not a big deal. I am also voting for such function. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unified DEPENDENCIES concept
On 09/08/2012 02:43 AM, Ciaran McCreesh wrote: On Fri, 07 Sep 2012 18:55:10 -0400 Michael Orlitzky mich...@orlitzky.com wrote: I think that dependencies are ultimately not hierarchical Situations like foo? ( bar? ( || ( a ( b c ) ) ) ) do happen, so any new syntax would have to be able to deal with that. The deps in both cases are just a collection of atom/type pairs, so anything possible in one must be possible in the other. I think this means, if USE=bar, then we need either a or (b and c)? It could be written, || ( a: bar? ( build run ) b,c: bar? ( build run ) ) Or if we wanted to make it even easier, allow the USE conditional at the top level like we do now: bar? ( || ( a: ( build run ) b,c: ( build run ) )) I'm just wondering if it wouldn't be nicer to think in terms of package atoms instead of the dependency types. Right now, we've got buckets named DEPEND, RDEPEND, etc. and we put the package atoms in those buckets. The above syntax would make the package atoms the buckets, and we would be putting the dependency types into the buckets instead.
Re: [gentoo-dev] python-distutils-ng.eclass: allow useflag dependencies for python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Where are your use cases? qgrep PYTHON_USE_WITH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQS0J1AAoJEFpvPKfnPDWzktAH/jY5/hfkIv6Gn+mRBg3ROtKh EQ0vAJV3ZXSsIlO7UOxJf79wj1TqiApAhXvUxs5orJKOuCqc3Pfq41KNV/KfyRiS zno/4sSVvgU6udSGx3BScbDIQi6T7bQKquP3FalDw30v2/xDqYdTPFCx+qfRG0Eu erquQOiMs2OzBBzQn95xnjGaWN7Z9QBmkdIS3pC4hB2hIGOQmBEskRCQVtA9mfog wM5war7DpTUsyrcJb67LZy0AeACN42xHJ7KFMkqVYp1WkT7Y04LmWmCjUJfSK7Yt osZ2r/SUpCHQ1cJ5LM5DunboV7j2DZGzyNvCM2N3phnfYbQWAxhWoI4Idc4YzqE= =KICW -END PGP SIGNATURE-
[gentoo-dev] making USE=upnp a global flag
i'm surprised this hasn't happened already. currently at 18 users (and i'm adding another), so time to make global. i'll use the description: upnp: Enable support for the Universal Plug and Play (UPnP) network protocol app-misc/tracker: Add support for video extraction via media-libs/gupnp-dlna. gnome-extra/nautilus-sendto: Enables support for sending files over upnp using net-libs/gupnp-av kde-base/kdelibs: Enable UPnP support media-plugins/grilo-plugins: Build support for UPnP devices using net-libs/gupnp and net-libs/gupnp-av media-sound/rhythmbox: Build a plugin for local network music sharing which uses UPnP protocols using media-video/coherence, dev-python/louie, and dev-python/twisted media-video/totem: Enable DLNA support through media-video/coherence media-video/vlc: Enables support for Intel UPnP stack. net-libs/farsight2: Enable UPnP IGD support net-libs/farstream: Enable UPnP IGD support net-libs/libnice: Enable UPnP IGD support net-misc/tor: Enable Universal Plug and Play net-p2p/amule: Enables support for Intel UPnP stack. net-p2p/bitcoin-qt: Enable Universal Plug and Play net-p2p/bitcoind: Enable Universal Plug and Play net-p2p/eiskaltdcpp: Forward ports using UPnP net-p2p/ktorrent: Forward ports using UPnP net-p2p/leechcraft-eiskaltdcpp: Forward ports using UPnP www-servers/pshs: Enable port forwarding using UPnP via net-libs/miniupnpc -mike
Re: [gentoo-dev] News item 1: changes to stages (make.conf and make.profile)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is the second draft for this news item. On 06-09-2012 03:52, Jorge Manuel B. S. Vicetto wrote: Hi. Following the July 24th thread about changing the default location of make.conf and make.profile in the new stages, I propose to commit 2 news items in 2 or 3 days. The first one (this one) is directed to all users and informs about the change and what to do. The second one (next email) will be directed to catalyst users. This news item should be presented to as many users as possible. Following Fabian's request in the previous thread, I'm trying to restrict it to default/linux profiles only. I don't know if it's possible to filter with default/linux/*, if there are other alternatives or if we will have to list *all* relevant profiles (the latter case is not appealing). Does anyone have any comments about this news item? Title: make.conf and make.profile move Author: Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org Content-Type: text/plain Posted: 2012-09-08 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-apps/portage Display-If-Keyword: alpha Display-If-Keyword: amd64 Display-If-Keyword: arm Display-If-Keyword: hppa Display-If-Keyword: ia64 Display-If-Keyword: m68k Display-If-Keyword: mips Display-If-Keyword: ppc Display-If-Keyword: ppc64 Display-If-Keyword: s390 Display-If-Keyword: sh Display-If-Keyword: sparc Display-If-Keyword: x86 Starting next week, new stages will have make.conf and make.profile moved from /etc to /etc/portage. This is a change in the installation defaults, that will only affect new installs so it doesn't affect current systems. Current users don't need to do anything. But if you want to follow the preferred location, you may want to take the chance to move the files in your system(s) to the new location. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQS4jTAAoJEC8ZTXQF1qEP9rkP/iaaHIZ43sBXim1Eb8lW4u/U E4Us9pzrdCqTiPdHZWzGpdsaUgJdFEVcF/6S+TMByJV5WZM17vcy0wI/9Fm92UKH /stZvOlECnCkCoASxSSzyjyfHOwio1G5A6oLWtfhTS8Mbbf28bny71iCgQN+MjDO 2asva5e04tEbe2yd/cQZfObf6npCmSb+tg94N8+dAu42uwtjZ1Zp1TcUZ0mP/PY9 2vs8joOOxvpnv5Azf8oz4p/g5dxWXVbGjZeJV7sBZKGbu2wpmeQsjYX3suE8r5gz d3ZMRFkGwYEmVWVXp4qNS36sik6h8++PsWPS+RJy/6W7IfWh21DHXVYrmEvPAxOU gSqJXPKwHu9a5DsVNf2fbgnDhOirx7gSgQBl2SwPZdpQ6Ts60h/Epn6oeDs8AXF0 B4MXQJUZV8AzXR7GQXnYDAIO+5FMyAPXJdxQ9MpoCP/ENrd+RBETiLDc6C7zfino DDxB2tUtA5pFx4scpJaOE2ZAD3vVSBG7cravSTHgD3xEnyf9elblAIzaE3ADYzgL 5UkR4kEcnzGuSOYUR0uZqrp7Xyz+Pb661bFbindzCpmqEaoOUQfkdBum+SD7eG8y h7XDzVBK0aNqsZ3STTfRn7OtJ5en7tUQJbznm69+DXz24WVk/r2zNr7NyWoNu/+J 0RKE6fzAHjTC6laxHJf5 =o5GT -END PGP SIGNATURE-
Re: [gentoo-dev] making USE=upnp a global flag
On Sat, 8 Sep 2012 10:37:49 -0700 Mike Frysinger vap...@gentoo.org wrote: i'm surprised this hasn't happened already. currently at 18 users (and i'm adding another), so time to make global. i'll use the description: upnp: Enable support for the Universal Plug and Play (UPnP) network protocol Not sure about that description. It's whole stack of protocols which usually benefit from more refined description. On the other hand, the local descriptions in the tree show that some people simply don't care and you are guessing what it does anyway... -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)
Jorge Manuel B. S. Vicetto posted on Sat, 08 Sep 2012 18:05:07 + as excerpted: Starting next week, new stages will have make.conf and make.profile moved from /etc to /etc/portage. This is a change in the installation defaults, that will only affect new installs so it doesn't affect current systems. Current users don't need to do anything. But if you want to follow the preferred location, you may want to take the chance to move the files in your system(s) to the new location. While the following reads somewhat smoother to me, maybe it's /just/ me, so another opinion would be appreciated. The current wording is already clear, so just going with it is fine with me. Starting next week, new stages will locate make.conf and make.profile in /etc/portage instead of /etc. This change to the installation defaults only affects new systems and both locations will continue to be supported. Whether you wish to move the files to their new /etc/portage location is therefore entirely up to you. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Unified DEPENDENCIES concept
On Fri, Sep 7, 2012 at 4:45 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Since DEPENDENCIES hasn't been written up in a Gentoo-friendly manner, and since the Exherbo documentation doesn't seem to suffice to explain the idea here, here's some more details on the DEPENDENCIES proposal. I like this. It seems well planned and thought out and very flexible. If I understand correctly paludis already supports this, so a working implementation is already available which is clearly beneficial for a proposal. Thanks a lot, Ciaran, for writing this up. Matt
[gentoo-dev] Perl: please don't delete packlists
I just tried (and failed) to pack a script with App::FatPacker and
noticed Gentoo follows the bad example of most other distributions in
removing all .packlist files from Perl module installations.
These files are the only system-independent way of determining which
modules belong together as part of a CPAN distribution, e.g. to find
that Template::Parser belongs to the Template Toolkit proper while
Template::Timer is an external add-on. FatPacker needs them to determine
which modules to pack into the archive that makes a standalone script
not requiring any external non-core modules, and so do various other
bits such as Module::Installed.
Can we please keep these? It's not like a handful of files with a couple
hundred bytes per installed module at worst made any significant
difference in either disk use or search times, but removing them is a
Bad Idea that probably came from Debian and needlessly breaks stuff.
I solved my problem by
a) removing the patches to ExtUtils::MakeMaker that delete packlist
creation from the perl and vendor targets in generated makefiles, and
b) modifying perl-module.eclass so it removes only empty *.bs files:
--- /usr/portage/eclass/perl-module.eclass.orig 2012-09-01 08:26:44.245212715
-0600
+++ /usr/portage/eclass/perl-module.eclass 2012-09-01 10:22:10.308419665
-0600
@@ -123,7 +123,7 @@
--installdirs=vendor \
--libdoc= \
--destdir=${D} \
- --create_packlist=0 \
+ --create_packlist=1 \
${myconf_local[@]}
einfo perl Build.PL $@
perl Build.PL $@ ${pm_echovar} \
@@ -341,8 +341,7 @@
debug-print-function $FUNCNAME $@
perl_set_version
if [[ -d ${D}/${VENDOR_ARCH} ]] ; then
- find ${D}/${VENDOR_ARCH} -type f -a \( -name .packlist \
- -o \( -name '*.bs' -a -empty \) \) -delete
+ find ${D}/${VENDOR_ARCH} -type f -a \( -name '*.bs' -a -empty
\) -delete
find ${D} -depth -mindepth 1 -type d -empty -delete
fi
}
The perl_delete_packlist() function should probably not be called that any more
as it only deals with DynaLoader files now but that would require changing a
few ebuilds as well:
dev-libs/libprelude
www-apache/mod_perl
net-analyzer/rrdtool
I think Gentoo of all distributions should aim to provide software as
original as possible. If there are any reasons that I have ignored so
far why people would want the current behavior, how about I make this
patch conditional on a new use flag?
cheers,
Matthias
signature.asc
Description: Digital signature
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
2012-09-04 22:50:16 Michał Górny napisał(a):
+ local slot=${1:-${BOOST_MAX_VERSION:-$(boost-utils_get_best_slot)}}
When BOOST_MAX_VERSION is non-empty, then it should be used in the following
way:
[[ ${BOOST_MAX_VERSION} =~ ^[[:digit:]]+\.[[:digit:]]+$ ]] || die Invalid
BOOST_MAX_VERSION
atom=$(best_version
dev-libs/boost-${BOOST_MAX_VERSION%.*}.$((${BOOST_MAX_VERSION#*.}+1))_alpha)
slot=$(get_version_component_range 1-2 ${atom#dev-libs/boost-})
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
