[gentoo-dev] Re: revbumping ebuilds after USE dependency changes
Michał Górny posted on Sun, 28 Jul 2013 11:11:13 +0200 as excerpted: > With a proper design, you have two 'repos': one with ebuilds, > and the other consisting purely of installed packages (vardb/system). > What's important, per definition vardb is self-satisfactory. That is, > dependencies of every installed package are supposed to be satisfied by > installed packages purely. > > Now, what portage does is implicitly applying _some_ of the metadata > from the ebuild tree to vardb without rebuilding the package. In some > cases. As an effect, vardb is no longer self-satisfactory, > and represents something between the package that was built and the > current ebuild. > > Ciaran has already elaborated a bit on the potential issues. It gets > most dangerous when you create some meaningful changes without a > revbump. I'll give you a simple example that I can think of. > > Say, you fix a semi-build-time issue of linking against unnecessary dep. > Users who build the ebuild from now on benefit by having less deps. The > dep is less problematic than rebuilding the package, so users who built > it before prefer to wait for next version. > > But in this case, portage may implicitly update the deps from ebuild > without rebuilding it. This means that users who still link against the > dep, may end up with the dep removed and program broken. This is an extremely good explanation (much better and shorter than I would/could have done, I believe). Thanks. The one thing it's missing, and that's more on the practical than theoretical end I believe the explanation was targeting, is that these days, portage's depclean has an additional level of caution/safety built- in, that in practice limits the damage quite a bit from what the above theory would predict, very likely in response to complaints about that very problem. I haven't checked the details and depclean does run far faster than revdep-rebuild so whatever it's doing isn't as thorough, but depclean now does at least some actual on-system checking before removing a package, and will refuse to remove a package it otherwise would (no database deps requiring it so the database says it's fine to remove) with an explanation of what's actually linked against it, if depclean's pre-clean scans indicate that removing the package would otherwise leave an unsatisfied/dangling linkage, asking you to rebuild the depending package first to remove that in-practice-but-not-in-database dependency. This behavior can actually be a bit frustrating if the depending package in question has an "automagic" dependency that will link against a package if it finds it installed, but doesn't declare it as a dep, as the requested rebuild won't solve the undeclared dependency in that case, so the depended package must be removed manually (using emerge --unmerge, which doesn't do this scan and has a nice scary warning to that effect) and the automagic-depending package rebuilt AFTER the depended package as been removed. That's actually how I ended up finding out how well depclean's scans work, since it said to rebuild a package that didn't declare a dependency, which I did, but that didn't solve the problem as it was an automagic dependency that was linked in as long as the files were found on the system to link against. The gentoo automagic-dependency bug I filed was initially closed as invalid, too, because the gentoo package maintaining dev wasn't in fact aware of depclean's then rather new ability to catch such problems, either. But I reopened, mentioning depclean's (then) new scanning and asking him to actually try it and to consult with Zac if he had questions about the (then) new behavior, which he evidently did, as the bug was fixed properly, automagic dependency converted into a USE flag covered dependency, with a comment to the bug thanking me for re-opening and alerting him to the problem. =:^) Altho I believe it's limited to elf-dependency checking and arguably isn't the best theoretical solution, in practice depclean's solution is rather nice, since it catches both dynamic-dep problems like those in this thread, and automagic-linking issues that no pure database solution could catch, since by definition, automagic dependencies are not declared in the database, or they'd be declared dependencies not automagic dependencies. (By the same token, it should catch dependencies for independently compiled and installed packages that are obviously not in the database except possibly via package.provided, as well. =:^) But I do believe depclean's scan won't catch python/perl/ruby/shell/etc dependencies, only elf-binary. That remains a problem, but one that for many gentooers anyway, isn't actually too big a deal in practice. -- 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
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-07-28 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-07-28 23h59 UTC. Removals: dev-ml/zero 2013-07-22 18:04:35 aballier sys-apps/module-init-tools 2013-07-23 11:12:27 ssuominen Additions: dev-ml/iTeML2013-07-22 00:52:55 aballier dev-db/pgbadger 2013-07-22 00:53:21 titanofold dev-libs/libsolv2013-07-22 04:14:06 scarabeus net-p2p/pybitmessage2013-07-22 22:02:09 hasufell dev-python/mozfile 2013-07-23 11:44:11 idella4 x11-terms/lilyterm 2013-07-23 14:57:02 jer dev-ml/cppo 2013-07-23 18:05:39 aballier mail-filter/exim-geoip 2013-07-23 18:17:05 grobian mail-filter/exim-p0f2013-07-23 18:18:48 grobian dev-perl/Net-SMTPS 2013-07-24 05:46:41 dev-zero app-vim/syntastic 2013-07-24 08:12:23 radhermit sec-policy/selinux-sensord 2013-07-24 19:39:00 swift dev-libs/libzypp2013-07-24 21:13:49 scarabeus sci-geosciences/gmapcatcher 2013-07-25 02:04:45 mrueg app-admin/zypper2013-07-25 15:36:36 scarabeus dev-php/pecl-redis 2013-07-26 15:57:39 olemarkus dev-ruby/heredoc_unindent 2013-07-26 20:22:38 mrueg dev-ruby/safe_yaml 2013-07-26 20:29:13 mrueg app-forensics/libbfio 2013-07-27 00:50:55 zerochaos virtual/pypy2013-07-27 11:15:48 mgorny dev-python/pypy-bin 2013-07-27 11:19:19 mgorny games-simulation/corsix-th 2013-07-27 11:41:13 miknix dev-python/python-nbxmpp2013-07-28 09:09:41 jlec -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-ml/zero,removed,aballier,2013-07-22 18:04:35 sys-apps/module-init-tools,removed,ssuominen,2013-07-23 11:12:27 Added Packages: dev-ml/iTeML,added,aballier,2013-07-22 00:52:55 dev-db/pgbadger,added,titanofold,2013-07-22 00:53:21 dev-libs/libsolv,added,scarabeus,2013-07-22 04:14:06 net-p2p/pybitmessage,added,hasufell,2013-07-22 22:02:09 dev-python/mozfile,added,idella4,2013-07-23 11:44:11 x11-terms/lilyterm,added,jer,2013-07-23 14:57:02 dev-ml/cppo,added,aballier,2013-07-23 18:05:39 mail-filter/exim-geoip,added,grobian,2013-07-23 18:17:05 mail-filter/exim-p0f,added,grobian,2013-07-23 18:18:48 dev-perl/Net-SMTPS,added,dev-zero,2013-07-24 05:46:41 app-vim/syntastic,added,radhermit,2013-07-24 08:12:23 sec-policy/selinux-sensord,added,swift,2013-07-24 19:39:00 dev-libs/libzypp,added,scarabeus,2013-07-24 21:13:49 sci-geosciences/gmapcatcher,added,mrueg,2013-07-25 02:04:45 app-admin/zypper,added,scarabeus,2013-07-25 15:36:36 dev-php/pecl-redis,added,olemarkus,2013-07-26 15:57:39 dev-ruby/heredoc_unindent,added,mrueg,2013-07-26 20:22:38 dev-ruby/safe_yaml,added,mrueg,2013-07-26 20:29:13 app-forensics/libbfio,added,zerochaos,2013-07-27 00:50:55 virtual/pypy,added,mgorny,2013-07-27 11:15:48 dev-python/pypy-bin,added,mgorny,2013-07-27 11:19:19 games-simulation/corsix-th,added,miknix,2013-07-27 11:41:13 dev-python/python-nbxmpp,added,jlec,2013-07-28 09:09:41 Done.
Re: [gentoo-dev] PYTHON flags grammar? why?
Dnia 2013-07-28, o godz. 17:07:20 "Walter Dnes" napisał(a): > On Sat, Jul 27, 2013 at 09:59:38AM +0200, Ulrich Mueller wrote > > > On Sat, 27 Jul 2013, Leho Kraav wrote: > > > > > php5-5 vs python2_7 > > > Why, how did that happen? > > > > Using the hyphen is cleaner, because the underscore is used as the > > separator for USE_EXPAND. > > > > (OTOH, as long a nobody will introduce a PYTHON_TARGETS_PYTHON2 > > variable, python2_7 will also work fine.) > > Out of sheer curiousity, why does make.conf need all 3 of... > > PYTHON_SINGLE_TARGET="python2_7" > PYTHON_TARGETS="python2_7" > USE_PYTHON="2.7" You could also search the archives instead of bringing up the same questions again. The whole rationale was there. And before yet another person asks: gmane! -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] PYTHON flags grammar? why?
On 28/07/13 05:07 PM, Walter Dnes wrote: > On Sat, Jul 27, 2013 at 09:59:38AM +0200, Ulrich Mueller wrote >>> On Sat, 27 Jul 2013, Leho Kraav wrote: >> >>> php5-5 vs python2_7 >>> Why, how did that happen? >> >> Using the hyphen is cleaner, because the underscore is used as the >> separator for USE_EXPAND. >> >> (OTOH, as long a nobody will introduce a PYTHON_TARGETS_PYTHON2 >> variable, python2_7 will also work fine.) > > Out of sheer curiousity, why does make.conf need all 3 of... > > PYTHON_SINGLE_TARGET="python2_7" Because some packages only accept a single version of Python. e.g. Blender, systemd. I think this also applies to the default Python version for packages that install executables. > PYTHON_TARGETS="python2_7" Because the Python ABI [*] requires different libraries to be built for different versions and installed in different places. /usr/lib/python?.? [*] not really a binary interface, but let's call it that > USE_PYTHON="2.7" This is deprecated, AFAIK and used for old packages that do not support PYTHON_TARGETS. (something to do with EAPI or eclass or something like that) signature.asc Description: OpenPGP digital signature
[gentoo-dev] PYTHON flags grammar? why?
On Sat, Jul 27, 2013 at 09:59:38AM +0200, Ulrich Mueller wrote > > On Sat, 27 Jul 2013, Leho Kraav wrote: > > > php5-5 vs python2_7 > > Why, how did that happen? > > Using the hyphen is cleaner, because the underscore is used as the > separator for USE_EXPAND. > > (OTOH, as long a nobody will introduce a PYTHON_TARGETS_PYTHON2 > variable, python2_7 will also work fine.) Out of sheer curiousity, why does make.conf need all 3 of... PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" USE_PYTHON="2.7" -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] PHP_TARGETS vs PYTHON_TARGETS different grammar, why?
Because it would require us to change a whole load more than just the targets variable. Plus we actually were the first coming up with the solution... Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Sun, Jul 28, 2013 at 5:22 PM, Brian Dolbec wrote: > On Sun, 2013-07-28 at 13:33 +0200, Dirkjan Ochtman wrote: > > On Sun, Jul 28, 2013 at 12:50 PM, Leho Kraav wrote: > > > Wondering if there's any plan for proper convergence at some point? > > > > I'd guess that the value of further convergence is so small that it > > will not be a priority for any of the teams. > > > > Cheers, > > > > Dirkjan > > > > Ruby team has been very vocal about NOT changing it's way in the past. >
Re: [gentoo-dev] PHP_TARGETS vs PYTHON_TARGETS different grammar, why?
On Sun, 2013-07-28 at 13:33 +0200, Dirkjan Ochtman wrote: > On Sun, Jul 28, 2013 at 12:50 PM, Leho Kraav wrote: > > Wondering if there's any plan for proper convergence at some point? > > I'd guess that the value of further convergence is so small that it > will not be a priority for any of the teams. > > Cheers, > > Dirkjan > Ruby team has been very vocal about NOT changing it's way in the past. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes
On 28 July 2013 21:11, Michał Górny wrote: > Now, what portage does is implicitly applying _some_ of the metadata > from the ebuild tree to vardb without rebuilding the package. In some > cases. As an effect, vardb is no longer self-satisfactory, > and represents something between the package that was built > and the current ebuild. > > Ciaran has already elaborated a bit on the potential issues. It gets > most dangerous when you create some meaningful changes without > a revbump. I'll give you a simple example that I can think of. > > Say, you fix a semi-build-time issue of linking against unnecessary > dep. Users who build the ebuild from now on benefit by having less > deps. The dep is less problematic than rebuilding the package, so users > who built it before prefer to wait for next version. > > But in this case, portage may implicitly update the deps from ebuild > without rebuilding it. This means that users who still link against > the dep, may end up with the dep removed and program broken. If there was a portage feature of some kind that triggered a rebuild when /var/db/* deps mismatched ebuild deps, I'd use that ( similar to how you can trigger a rebuild when USE changes ) I'm one of those people who doesn't mind installing the same thing a million times a week =) -- Kent
Re: [gentoo-dev] PHP_TARGETS vs PYTHON_TARGETS different grammar, why?
On Sun, Jul 28, 2013 at 12:50 PM, Leho Kraav wrote: > Wondering if there's any plan for proper convergence at some point? I'd guess that the value of further convergence is so small that it will not be a priority for any of the teams. Cheers, Dirkjan
Re: [gentoo-dev] PHP_TARGETS vs PYTHON_TARGETS different grammar, why?
On 27.07.2013 11:08, Michał Górny wrote: Dnia 2013-07-27, o godz. 10:37:04 Leho Kraav napisał(a): php5-5 vs python2_7 Why, how did that happen? Because some people like to type 'php_targets_php5-5'. Thanks everyone for replying. Wondering if there's any plan for proper convergence at some point?
Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes
Dnia 2013-07-25, o godz. 17:07:00 Michael Palimaka napisał(a): > On 25/07/2013 05:17, Michał Górny wrote: > > Actually per PMS you are required to revbump (and therefore require > > upgrade on users' side) whenever you change the deps and don't expect > > to add a new version soon enough. > > Can you please provide a link/reference to that part? I am interested in > reading more about it. To be honest, I have no idea if that's worded at all since PMS doesn't cover vardb. I may have overused the term 'per PMS' then. However, this is what Brian & Ciaran (at least) were criticizing for some time. The idea is that when you build an ebuild, you are basically either creating a binary package or installing a package to the system (or both). Along with that, metadata is transferred from the ebuild to the package or vardb. With a proper design, you have two 'repos': one with ebuilds, and the other consisting purely of installed packages (vardb/system). What's important, per definition vardb is self-satisfactory. That is, dependencies of every installed package are supposed to be satisfied by installed packages purely. Now, what portage does is implicitly applying _some_ of the metadata from the ebuild tree to vardb without rebuilding the package. In some cases. As an effect, vardb is no longer self-satisfactory, and represents something between the package that was built and the current ebuild. Ciaran has already elaborated a bit on the potential issues. It gets most dangerous when you create some meaningful changes without a revbump. I'll give you a simple example that I can think of. Say, you fix a semi-build-time issue of linking against unnecessary dep. Users who build the ebuild from now on benefit by having less deps. The dep is less problematic than rebuilding the package, so users who built it before prefer to wait for next version. But in this case, portage may implicitly update the deps from ebuild without rebuilding it. This means that users who still link against the dep, may end up with the dep removed and program broken. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] default bashrc value suggestion
On Sat, 27 Jul 2013 21:08:39 +0200 Chí-Thanh Christopher Nguyễn wrote: > Jeroen Roovers schrieb: > > To summarise: > > > > 1) locale related ebuild problems should be fixed in the > >relevant ebuilds/eclasses, because: > > 2) globally forcing a locale to fix one ebuild will expose build issues > >in other ebuilds (there is no generic solution) > > 3) several people have been adamant that locale settings should not be > >forced upon Gentoo users. > > 4) use the translation service of your choice to find out what the > >(usually generic) messages mean. > > Nobody seemed to be against setting LC_MESSAGES in make.conf. > I reported a bug now. > https://bugs.gentoo.org/478382 I've been pretty vocal against this in the past so I just wanted to say I have no problem setting a default in make.conf. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
