Re: [gentoo-dev] How not to discuss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Piotr Jaroszyński wrote:
I think what you are missing is that some people (me included) think
that the in-file approach is the cleanest and most obvious solution
(which also happens to not hurt performance). So if you want bad
design to be an objective argument you need to back it up with
something concrete. For example, could you foresee any actual problems
of the in-filename approach? Cause all I was hearing was it doesn't
look nice which now is oh no, don't expose metadata. The former is
clearly subjective and the latter is already done ($PN-$PV) and
doesn't seem to cause any problems.
What we care about doing is being able to install a package of a known name, PN,
with a known version, PV, and we may even want to make sure that the revision,
PR, is just right. Therefore PN, PV and PR are not metadata, but actual data to
identify a specific software unit. (This is also why PR should be bumped if (and
mostly only if) there are changes to files that will be installed.)
On the other hand, EAPI is a value that encodes what is valid in an ebuild and
as such is an implementation detail. Exposing implementation details is bad
design.
Actually I think just changing extensions is also an implementation detail. If
we need the user to make certain upgrades (portage, bash) before being able to
use certain ebuilds then we should just tell them. What else are news items for?
As long as we provide an upgrade path from version X_years_old to version
X_days_old via versions A, B and C, I think we have done our part. In fact we
already had one such situation with bash and portage.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkofqY4ACgkQp/VmCx0OL2xOLQCgqkXnwaThpT2oOdpiliS7SHRa
pt8An3/S6O+LiXkzQBRPsw0zRUmxhNZp
=Ntpj
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: GLEP 55: another approach: display pretty messages with old PMs
On Fri, 2009-05-29 at 10:42 +, Duncan wrote: Michael Haubenwallner ha...@gentoo.org posted on Fri, 29 May 2009 10:14:46 +0200: Ohw, the latter would be necessary here, or '4.ebuild' would not be found. s/4.ebuild/4.eclass/ I assume. Indeed. Except... since an ebuild must presently be sourced to (properly) determine EAPI, it still doesn't work for changes that break sourcing or other pre-EAPI processing (like parsing PN and PVR out of the filename), so the changes allowed with a simple EAPI change are still rather limited. As long as the *whole* ebuild content (including the filename) needs to be successfully interpreted just for EAPI detection, we will have to change the extension or wait the extended period for each incompatible EAPI change. So this full interpretation for EAPI detection doesn't feel like a good way to go at all. That's why the change to GLEP55 or alternative, whether in-filename or in-file-itself, will again require either an extended wait after introduction (the old way) or at minimum, a one-time change to extension such that old PM versions don't even see the currently EAPI incompatible changes. Wouldn't it be possible to avoid both the extension change and another extended wait period for new incompatible(*) EAPIs, when we do this early and silent exit hack for unsupported ebuilds with old PMs that still do full interpretation for EAPI detection? And after another extended wait period(**), we can start dropping the silent exit hack, so we finally have switched to EAPI detection without full interpretation, but still have the .ebuild extension. (*) The incompatibility of EAPIs must not begin (meaning the bytewise ebuild content) before the end of both the ebuild's EAPI value definition and the silent exit hack. But this IMO is an acceptable compromise. (**) After this wait period, the incompatibility of EAPIs can start after the end of the ebuild's EAPI value definition. Thanks! /haubi/ -- Michael Haubenwallner Gentoo on a different level
[gentoo-dev] Re: GLEP 55: another approach: display pretty messages with old PMs
Michael Haubenwallner ha...@gentoo.org posted 1243610264.27150.293.ca...@sapc154.salomon.at, excerpted below, on Fri, 29 May 2009 17:17:44 +0200: Wouldn't it be possible to avoid both the extension change and another extended wait period for new incompatible(*) EAPIs, when we do this early and silent exit hack for unsupported ebuilds with old PMs that still do full interpretation for EAPI detection? Possibly. I forgot about the context (the inherit eapi.eclass hack) when I wrote the previous (until /after/ I posted, naturally, probably when you noticed that 4.ebuild thing too, of course =:^). But the possibility had been proposed before and I don't remember what came of it, nor have I been following close enough to know if there's another caveat somewhere that shoots down the eapi.eclass hack, or not. I'm sure someone else will supply the reason it didn't go anywhere. -- 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] RFC: ACCEPT_LICENSE default value (GLEP 23)
Hi, In the context of my GSOC [1] I need to get GLEP 23 [2] fully implemented and this means get ACCEPT_LICENSE used with a default value and bug 152593 [3] fixed. = GLEP 23 summary = Most of GLEP 23 features have already been implemented in portage. Some since a long time (at least in stable portage) like multiple licenses and conditional licenses. License group and ACCEPT_LICENSE is already implemented in portage 2.2 (masked). = ACCEPT_LICENSE = Please, have a look at GLEP 23 [2] and read how ACCEPT_LICENSE and license groups work (it's the main topic). I will repeat some things above but not everything. ACCEPT_LICENSE, as ACCEPT_KEYWORDS, will mask/unmask packages based on the license. User will explicitely know why the package is masked and which license to accept to have it unmasked. The path of the license is showed to incite him read it. This feature should help bug 152593 [3] because if he accepts the license, we can assume he known what he was doing (ie. we can assume he read the license) but we will see that in the last part. = ACCEPT_LICENSE default value = The ACCEPT_LICENSE default value will impact users, devs and Gentoo. Users: ebuilds will be masked if their license(s) is(are) not in ACCEPT_LICENSE Devs: they will have to maintain license groups and if a specific group is allowed by default (or not allowed by default) they will have to make sure new ebuilds are correctly (un)masked. Gentoo: we can consider (at least I) that such a value is important and linked to our social contract. Are we going to support FSF approved licenses ? OSI approved ? both ? union of them ? or event more licenses ? This decision is probably more than only user/dev issue. There are two ways to see the default value: set it to a set of groups which will allow automatically a set of licenses or set it to everything excluding a set of groups. In other words: accept_licen...@approved or ACCEPT_LICENSE=* -...@need_to_be_accepted That's a main difference because if not checked, an ebuild will be automatically masked for license in the first way and automatically unmasked in the second. There are some proposition of ACCEPT_LICENSE values for both ways. * accept_licen...@non_eula With this value, every license that is not an EULA will have to be in @NON_EULA group to let the ebuild available. PRO: easy for user, except for a few licenses, he will never notice this new feature. CON: difficult to maintain for devs: @NON_EULA will be big and you will have to think about adding a license to @NON_EULA when pushing it to the tree. * ACCEPT_LICENSE=* -...@eula That's actually the unique reason to use the second way (ie. all licenses accepted except some): masks all EULA. For the user, it's exactly the same if everything is done correctly by devs but if the dev forget to add a license to the right group, consequences will be different. With this default value, the package will be unmasked by default. In my opinion, the previous default value proposition is in all ways better than this one. It's probably better to have a forgotten license masked than unmasked because users will surely complain/file a bug if the package is masked. * accept_licen...@gentoo_approved @GENTOO_APPROVED will be a group of approved licenses. It will be different from NON_EULA as it could be a more restrictive set of licenses like a combination between @FSF_APPROVED and @OSI_APPROVED. In other words, what general people call free software. According to our social contract [4] we support free software and want Gentoo related work to be licensed in OSI approved license. And still according to this page, someone (who ?) is thinking about restrict Gentoo related work to OSI approved _and_ FSF approved licenses. Why not set ACCEPT_LICENSE to this same licenses ? It will be more consistent with our social contract. PRO: more consistent with social contract less work for dev than accept_licen...@non_eula as we can suppose @OSI_APPROVED and/or @FSF_APPROVED will not change often CON: users will probably have more masked packages because of licenses [5] = About licenses which needs explicit acceptance = This is not the main topic, but it could be interesting to have your opinions. It looks like some licenses need acceptance. I was thinking using a software means accepting the license. If we really need to make a user accept a license, printing the license path is enough ? He still can add the license name in ACCEPT_LICENSE without even reading it. However, I suppose adding the license name will be enough for an approval. This leads me to think ACCEPT_LICENSE=* should be forbidden. The point of this message is to get opinions of devs to reach a consensus then have this default value approved by the Council. So, what's your opinion ? [1] My GSOC is about writing a portage's backend for PackageKit. I will try to send a message about it in the next days. [2] http://www.gentoo.org/proj/en/glep/glep-0023.html [3]
Re: [gentoo-dev] Re: How not to discuss
On Friday 29 May 2009 04:12:04 Ryan Hill wrote: On Thu, 28 May 2009 08:28:12 +0200 Patrick Lauer patr...@gentoo.org wrote: This is becoming a rather lengthy email ping pong, but as people seem to be unable to discuss things I had to highlight a few issues there. I'm sorry to be rude, Don't be, most other posters on this list have no guilt either ... but ever consider that the reason people keep repeating things to you is that you continually misunderstand what they're saying? I'd say it is more the refusal of certain people to discuss at all. The constant attempts to shove a rational discussion into emotional pockets makes it quite hard to get any information out of it, statements like: No, it's entirely objective. GLEP 55 clearly shows how the filename based options are objectively better than anything else. are just wrong. It ignores one side of the conversation completely, not even accepting any potential value in their contribution. It's not a way to lead a technical discussion, and I'll do what I can to reduce such sophistry so we can _discuss_ things rationally. If anyone needs help - there's a few experienced engineers on this list that can help you get your ideas into a form that can be presented, discussed and improved without having to repeatedly ask for clarification what the actual problem is. Don't be afraid to learn from them. I think that by now we've exhausted everything that can possibly be said about GLEP 55. Nothing in this discussion is new, nor has it been for some time. Can we please just stop now and trust the representatives that we've elected to make their decision? Or should we go around the ring one more time? Looking at how it went last time ... prepare for at least two further rounds of trying to convince people that their feelings are wrong. That, of course, is doomed to failure because our subjective reality cannot be falsified, but facts (and their darn liberal bias!) or logic are usually only accidentally involved.
Re: [gentoo-dev] How not to discuss
On Thu, May 28, 2009 at 12:15 PM, Joe Peterson lava...@gentoo.org wrote: Alec Warner wrote: No, it's entirely objective. GLEP 55 clearly shows how the filename based options are objectively better than anything else. But the decision will not be based entirely on objective merits (although I will concede that EAPI in filename is the 'best' technical choice). (Jeez, I hate to add another to this thread, but this way of defining 'technical' bothers me) Lets agree to disagree on the definition of technical then and instead agree that putting EAPI in the filename is a bad design decision (technicalness aside) and then have a beer! Along the lines of what Roy so eloquently expressed, I think it's important that we do not divorce *design* from *technical*. The decision of where to place the EAPI is a design issue, and many of us here clearly believe that it is *not* good design to put this kind of metadata in the filename. Therefore, the statement that it is the 'best' technical choice is not objectively true. Technical issues of performance and efficiency can be addressed when proper design has been done beforehand. Part of the purpose of the implementation (after proper design is in place) is to address performance and other related issues. And part of the design is how we define the *interface*. The filename is clearly part of the interface. It is part of how devs (and users) interact with portage when writing ebuilds. Much of the argument for EAPI in the filename has been motivated by a perceived implementation benefit of speed, as if there were no other solutions (which is naive). As Roy suggested, if all engineering decisions were based purely on pragmatic ease of implementation factors, we'd have a lot of ugly designs/interfaces out there. It may be easy (although incorrect) to dismiss elegance/design/interface issues as non-technical, but I maintain they actually *are* technical matters of great importance. I've been an engineer for over 20 years, and I have seen the pitfalls of taking the quick-and-dirty approach just to slap a new feature into a software app. I've seen how such hasty design mistakes can cause great pain and regret for a long time after. Let's get the design right, first. For what it's worth, GLEP 55 does now provide an option (#3: Easily fetchable EAPI inside the ebuild and one-time extension change) that demonstrates good design. -Joe
Re: [gentoo-portage-dev] Conflicting RDEPENDS
On Fri, May 29, 2009 at 01:36:20AM +0200, René 'Necoro' Neumann wrote:
Package spam rdepends on =eggs-2.
Package bacon rdepends on =eggs-1.
So in theory there should be no way of installing them together (given
that eggs is not slotted). This works if I try to install them in one go.
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
app-test/eggs:0
('ebuild', '/', 'app-test/eggs-2', 'merge') pulled in by
=app-test/eggs-2 required by ('ebuild', '/', 'app-test/spam-1', 'merge')
('ebuild', '/', 'app-test/eggs-1', 'merge') pulled in by
=app-test/eggs-1 required by ('ebuild', '/', 'app-test/bacon-1',
'merge')
It looks different, if spam is installed and I try to install bacon
additionally:
# emerge -1av bacon
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild UD] app-test/eggs-1 [2] 0 kB [1]
[ebuild N] app-test/bacon-1 0 kB [1]
This second behavior looks wrong to me, as it downgrades the RDEPEND of
spam and thus spam becomes unusable.
Try: emerge -1av --complete-graph bacon
Unless --complete-graph is specified emerge won't pull in the entire
dependency graph, thus won't notice the dependency-spec of
app-test/spam.
Using -D combined with the world set when updating your system yields
the same result as that also pulls in the entire dependency graph.
Unless the entire dependency graph is pulled in emerge only tries to
satisfy the dependencies of the packages given on the commandline, and
since there's no connection between app-test/spam and app-test/bacon,
and emerge doesn't do reverse deps when adding something to the
dep-graph, it doesn't notice that app-test/bacon and app-test/spam has
conflicting dependencies
Using --complete-graph is noticably slower since it slows down
dependency calculations, but it should (IMHO) really be the default
since these conflicts shows _before_ anything breaks.
Re: [gentoo-portage-dev] Conflicting RDEPENDS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ferris McCormick schrieb: It looks different, if spam is installed and I try to install bacon additionally: # emerge -1av bacon These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] app-test/eggs-1 [2] 0 kB [1] [ebuild N] app-test/bacon-1 0 kB [1] What happens if you use emerge -1avD bacon Does not work either. This second behavior looks wrong to me, as it downgrades the RDEPEND of spam and thus spam becomes unusable. Yeah, it does look wrong, but I don't think it is. Ideally, I suppose eggs-1 could depend on !=app-test/spam-1 and so on, but that requires coordination among developers. I suppose there is a bug in the ebuilds because they should be set up so that if you have spam installed, you can't install bacon and so on. I think, this would be the wrong way., as they block each other already because of the RDEPEND. Else one would have to check the whole tree for a conflicting RDEPEND and then adding a whole bunch of blocks. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkofqzsACgkQ4UOg/zhYFuD4XQCeKUuemmNjWr7shtgsttc93sro 1U0An0SrsWexvLUmYtvzyjokpZiQyqSm =vvTO -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Conflicting RDEPENDS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Börjesson schrieb: # emerge -1av bacon These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] app-test/eggs-1 [2] 0 kB [1] [ebuild N] app-test/bacon-1 0 kB [1] This second behavior looks wrong to me, as it downgrades the RDEPEND of spam and thus spam becomes unusable. Try: emerge -1av --complete-graph bacon Ok - this works ... IF spam is in world. If I installed spam with - --oneshot, it won't work either. Unless --complete-graph is specified emerge won't pull in the entire dependency graph, thus won't notice the dependency-spec of app-test/spam. Using -D combined with the world set when updating your system yields the same result as that also pulls in the entire dependency graph. Unless the entire dependency graph is pulled in emerge only tries to satisfy the dependencies of the packages given on the commandline, and since there's no connection between app-test/spam and app-test/bacon, and emerge doesn't do reverse deps when adding something to the dep-graph, it doesn't notice that app-test/bacon and app-test/spam has conflicting dependencies Using --complete-graph is noticably slower since it slows down dependency calculations, but it should (IMHO) really be the default since these conflicts shows _before_ anything breaks. I agree. Regards, René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkofq+sACgkQ4UOg/zhYFuBhsACdEUiXen0NriASzULe0Ak9Waiv 6v8An1OxTqmbnhlCk7sRG0pYxfHJad8Y =Haya -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Conflicting RDEPENDS
On Fri, May 29, 2009 at 2:33 AM, René 'Necoro' Neumann li...@necoro.eu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Börjesson schrieb: # emerge -1av bacon These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] app-test/eggs-1 [2] 0 kB [1] [ebuild N] app-test/bacon-1 0 kB [1] This second behavior looks wrong to me, as it downgrades the RDEPEND of spam and thus spam becomes unusable. Try: emerge -1av --complete-graph bacon Ok - this works ... IF spam is in world. If I installed spam with - --oneshot, it won't work either. So don't use --oneshot :) Unless --complete-graph is specified emerge won't pull in the entire dependency graph, thus won't notice the dependency-spec of app-test/spam. Using -D combined with the world set when updating your system yields the same result as that also pulls in the entire dependency graph. Unless the entire dependency graph is pulled in emerge only tries to satisfy the dependencies of the packages given on the commandline, and since there's no connection between app-test/spam and app-test/bacon, and emerge doesn't do reverse deps when adding something to the dep-graph, it doesn't notice that app-test/bacon and app-test/spam has conflicting dependencies Using --complete-graph is noticably slower since it slows down dependency calculations, but it should (IMHO) really be the default since these conflicts shows _before_ anything breaks. I agree. Regards, René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkofq+sACgkQ4UOg/zhYFuBhsACdEUiXen0NriASzULe0Ak9Waiv 6v8An1OxTqmbnhlCk7sRG0pYxfHJad8Y =Haya -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Conflicting RDEPENDS
On Fri, May 29, 2009 at 11:33:31AM +0200, René 'Necoro' Neumann wrote: Patrick Börjesson schrieb: # emerge -1av bacon These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] app-test/eggs-1 [2] 0 kB [1] [ebuild N] app-test/bacon-1 0 kB [1] This second behavior looks wrong to me, as it downgrades the RDEPEND of spam and thus spam becomes unusable. Try: emerge -1av --complete-graph bacon Ok - this works ... IF spam is in world. If I installed spam with --oneshot, it won't work either. Why exactly would you want to use --oneshot for a leaf package that is not depended on by any other package in the world set? If spam IS depended on by any other package (recursively) in the world set, it will be pulled in by --complete-graph, but that's not the case here if i understand it correctly, thus it's a package that you explicitly wanted installed, thus it belongs in the world set, and you should thus not use --oneshot for it.
[gentoo-portage-dev] Re: Conflicting RDEPENDS
Patrick Börjesson psychoti...@lavabit.com posted 20090529201741.gb11...@nexon.nexus, excerpted below, on Fri, 29 May 2009 22:17:41 +0200: Why exactly would you want to use --oneshot for a leaf package that is not depended on by any other package in the world set? If spam IS depended on by any other package (recursively) in the world set, it will be pulled in by --complete-graph, but that's not the case here if i understand it correctly, thus it's a package that you explicitly wanted installed, thus it belongs in the world set, and you should thus not use --oneshot for it. I use -1 by default, here (via scriptlet), mainly so I don't have to worry about cluttering up my world file while emerging individual packages, just as I always use -NuD with my @system and @world runs. But for leaf packages, it serves as a sort of test install as well. Since I always do revdep-rebuild -p and emerge --depclean -p after every update (typically 2-3 times a week), then rebuild and clean as I need to, keeping the trial merges on the depclean list for a few days keeps me aware of them. If I know it's something I want to keep, I run a different scriptlet without the -1, but that's not often once a system is up and running with the normal working set merged. Meanwhile, I ultimately either emerge -C (or let depclean handle it) the trialware, or emerge --noreplace, thus adding it to world. But experimental installs and their deps typically sit in the --depclean list for anything from a few minutes to a few days, until I decide whether I want to keep or remove them. If he was testing how the switches under discussion here worked and has a similar policy, I could easily see him using -1 by habit, even if he didn't explicitly reason that it was a test and therefore something he didn't want in @world. -- 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
