Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*
On Wed, 2024-09-11 at 09:33 +0200, Jaco Kroon wrote: > Hi, > > I missed this announcement, looking specifically for composer again. > > If I make the effort of bumping to newest version, is this something > that would be re-added to the tree? I'd re-commit if you're interested in keeping up with it. It brings a lot of dependencies with it though. It was initially added in https://github.com/gentoo/gentoo/pull/2905 (where you can see the deps) and I'll bet the list is even longer now. Updating them is more annoying than usual because they all want autoload.php files that aren't in the source tarball: https://wiki.gentoo.org/wiki/Composer_packaging IIRC the "classmap" format is particularly annoying because you have to regenerate it with every release.
Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*
On 2024-09-11 17:23:16, Jaco Kroon wrote: > 1. Let users (myself included) just download and use that. > 2. We package the phar file rather than the individual deps. Yes, this > is cheating. Like using embedded libs, however, I've seen and observed > that in some cases this makes more sense than splitting them up (eg > clippy and frr). > 3. We go about figuring everything out again and bumping all those > individual packages and keeping them all up to date individually. I > don't think this is worth our time and effort. > > I honestly think in this case 2 may well be acceptable. Otherwise 1, but > I think 3 is not worth the effort based on your feedback and further > reading from when I originally posed the question to now. I agree that (3) is probably too much trouble. It might be worth it if someday people want to bring back other packages that would benefit from the deps, like PHPUnit. I don't like (2) because there's no way for the security team to know what's inside composer.phar, and no way for users to tell that they've got ~15 bundled dependencies in a tool that's extremely sensitive. So... what I've been doing is putting composer.phar in /usr/local/bin. (I also run it as a separate user because I don't trust the code it's downloading but that has nothing to do with Gentoo.)
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/07/2012 03:41 PM, Ulrich Mueller wrote: *** Proposal 2: "EAPI in header comment" *** A different approach would be to specify the EAPI in a specially formatted comment in the ebuild's header. No syntax has been suggested yet, but I believe that the following would work as a specification: - The EAPI must be declared in a special comment in the first line of the ebuild's header, as follows: - The first line of the ebuild must contain the word "ebuild", followed by whitespace, followed by the EAPI, followed by end-of-line or whitespace. Someone suggested using a standard shebang the last time this came up, and if I remember correctly it was one of the least-disagreeable solutions proposed. We could of course define our own custom format, but I think something like, #!/usr/bin/eapi5 would be perfect if we could hand off the interpretation of the ebuild to that program. That solves the problem with new bash features, too, since you could point that command at a specific version.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/08/2012 07:03 AM, Michał Górny wrote: Someone suggested using a standard shebang the last time this came up, and if I remember correctly it was one of the least-disagreeable solutions proposed. We could of course define our own custom format, but I think something like, #!/usr/bin/eapi5 would be perfect if we could hand off the interpretation of the ebuild to that program. That solves the problem with new bash features, too, since you could point that command at a specific version. And what would /usr/bin/eapi5 do? Are you suggesting misusing shebang or making ebuilds PM-centric? I was saying that I'd prefer a more-standard use of the shebang (if possible), rather than defining our own header comment syntax. Either way I think the second option is cleaner than regular expressions. Right now, we're guaranteed the features of bash-3.2. I guess we actually use whatever is executing ebuild.sh to source them. But we need to interpret the ebuild file with something: we might as well put *that* in the shebang, since that's what it's for. So if we were to do this with an ebuild right now, we'd add, #!/usr/bin/eapi4 to the header, and instead of sourcing the ebuild with whatever ebuild.sh is using, we would run it with 'eapi4' and pass whatever we need back and forth. Or maybe ebuild.sh would reload itself using 'eapi4'. If any of that makes sense, the PMS would just need to specify some requirements on the shebang command.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/07/2012 03:41 PM, Ulrich Mueller wrote: *** Proposal 1: "Parse the EAPI assignment statement" *** There's also libbash now: http://www.gentoo.org/proj/en/libbash/index.xml Anyone know how close we are to being able to use it to parse the EAPI?
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/08/2012 12:28 PM, Michał Górny wrote: And something will need to provide that /usr/bin/eapi4 thing. And that introduces new problems: I'm just parroting someone else's suggestion; I don't really know enough about the details to answer these properly. Not that that will stop me. 1) how are we going to support multiple package managers? will we need to install eapi4 thing as a smart wrapper choosing the right PM? 2) what about Prefix? #!/usr/bin/env eapi4 then, or proactive updating of shebangs in synced ebuilds? and then regenerating the whole cache (guess how long does it take to update it), Wouldn't #!/use/bin/env eapi4 handle both (1) and (2)? You might have to eselect package-manager or something first if you want to use two PMs at once. 3) what should happen if user executes ebuild? the ebuild should merge itself? with dependencies or without? If a user marks the ebuild executable and does ./foo-x.y.ebuild, the eapi4 wrapper can decide what to do. Nothing at all, print larry the cow, or crash (what we do now) are all fine with me =)
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/08/2012 12:53 PM, Ciaran McCreesh wrote: On Thu, 08 Mar 2012 12:48:51 -0500 Michael Orlitzky wrote: On 03/08/2012 12:28 PM, Michał Górny wrote: And something will need to provide that /usr/bin/eapi4 thing. And that introduces new problems: I'm just parroting someone else's suggestion; I don't really know enough about the details to answer these properly. Not that that will stop me. It probably should. Although in the early days the model for ebuilds was that they were scripts that were "executed", nowadays there's so much support required that it's better to think of ebuilds as being data. If you did have a /usr/bin/eapi5, it would have to be implemented as something that invoked the package manager, not as a direct interpreter. Fair enough, but aren't you arguing the opposite point with Zac? If ebuilds are data, fine, we write EAPI=4 somewhere and be done with it. Anything not having that format is out-of-spec. If they're code, they're code, and we need to execute them somehow. And the reason for the proposal in the first place was that the way we do it now ain't so great, eh?
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/08/2012 01:48 PM, Ciaran McCreesh wrote: If they're code, they're code, and we need to execute them somehow. The notion of "execute them somehow" that's used doesn't fit in with the #! interpreter model. You aren't executing ebuilds via an interpreter. You're performing an action that involves using the data and code in an ebuild multiple times and in multiple different ways, and that may also involve doing the same to an installed package that is being replaced. I do understand that; but the fact that the data are computed in an ugly turing-complete language complicates things. Did someone already propose replacing EAPI=foo with a function call akin to inherit? eapi 4 inherit whatever ... the call to eapi() would then set $EAPI accordingly. If the ebuild is being executed directly, it could exit $EAPI; otherwise, it would continue normally. That would give us an interface to the variable, and we wouldn't need to know the EAPI ahead of time to do it as long as it's the first function called in the ebuild. This is of course isomorphic to requiring a specific EAPI=4 format, but does allow you to do stupid things like x=`seq 4 4`; eapi $x; if you want.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/2012 12:04 AM, Michał Górny wrote:
This is of course isomorphic to requiring a specific EAPI=4 format,
but does allow you to do stupid things like x=`seq 4 4`; eapi $x; if
you want.
What advantage does it give us? We still can't change ebuild syntax in
global scope because bash will barf.
Not in EAPI=5, no, but once all PMs are using the eapi function we could.
The function can do any crazy thing you want. Right now, we need to
source the entire ebuild to get at its environment. Before we source it
for real, we just want to know the value of $EAPI. Since eapi() will be
the first function called, it can be our interface to this variable.
Here's a stupid but hopefully clear example:
$ cat test.ebuild
eapi 4
HOMEPAGE="http://www.example.com/";
echo "test.ebuild, current EAPI=${EAPI}"
$ cat test-sourcer.sh
#!/bin/bash
function eapi() {
if [ "$TELL_ME_YOUR_EAPI" == 1 ]; then
exit $1
fi
export EAPI=$1
}
export TELL_ME_YOUR_EAPI=1
`eval 'source test.ebuild'`
echo "Found EAPI: $?"
export TELL_ME_YOUR_EAPI=0
source test.ebuild
This sources it once, which short-circuits at the eapi() call returning
'4'. Then we source it a second time with EAPI=4, and see that it makes
it past the call to eapi() where any incompatible features would be.
$ ./test-sourcer.sh
Found EAPI: 4
test.ebuild, current EAPI=4
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 00:51, Zac Medico wrote: > On 03/08/2012 09:35 PM, Michael Orlitzky wrote: >> The function can do any crazy thing you want. > > We don't need a function. We need to know the EAPI before we source the > ebuild, and a function doesn't give us that. Surely we can source one or two lines of the ebuild safely, like the example shows?
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 10:05, Zac Medico wrote: >> >> Surely we can source one or two lines of the ebuild safely, like the >> example shows? > > Why would we though, when sourcing is a relatively costly operation, and > there are much more efficient ways to get the EAPI? There do not seem to be any that people agree on =) I mean, it's /easy/ to get the EAPI. There's a list of ways on the GLEP, but all of them have trade-offs. The header comment seems to be the preference in this thread. The advantage that the eapi function has over a comment is that it's not magic -- it's just normal bash syntax. So we've addressed that issue at a small performance cost (we're really only sourcing the ebuild up to 'exit'). Whether or not that trade-off is worth it, who knows. I would prefer to make it work before we make it fast; but new ideas can't hurt considering nobody has agreed on an old one. > Also, you've got a chicken and egg problem, since you're assuming that > your eapi() function is going to be available in the global environment > when the ebuild is sourced. The whole point of knowing the EAPI in > advance is so that we will be able to make changes to the global > environment, such as add, remove, or change the behavior of _any_ function. Nah, at the top of the ebuild, you would have, EAPI=5 eapi 5 until package managers catch up, just like we would have to do with the comment. Once they've caught up, we can drop the EAPI= assignment, and begin using new features after the call to 'eapi'.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 10:58, Zac Medico wrote: > On 03/09/2012 07:51 AM, Alexis Ballier wrote: >> On Fri, 09 Mar 2012 07:41:09 -0800 >> Zac Medico wrote: >> >>> On 03/09/2012 07:21 AM, Michael Orlitzky wrote: >>>> The advantage that the eapi function has over a comment is that >>>> it's not magic -- it's just normal bash syntax. So we've addressed >>>> that issue at a small performance cost (we're really only sourcing >>>> the ebuild up to 'exit'). >>> >>> Also consider the case where a user syncs after not having updated >>> for a couple of months, and the tree contains some ebuilds with EAPIs >>> that are not supported by the currently installed package manager. >>> >>> In this case, when resolving dependencies and filtering ebuilds based >>> on whether or not their EAPI is supported, spawning bash once per >>> ebuild is much more costly than the alternatives. >> >> isnt the whole point of the proposal to get eapi without sourcing ? >> >> so that we can use new bash features at local or global scope without >> risking that people with an old bash get syntax errors trying to get >> the eapi > > Right. Michael has lost sight of the goal and is moving off on a tangent. The point was to be able to get the EAPI without crashing if the ebuild uses newer features. If you can get the EAPI without sourcing, that obviously accomplishes the goal. But there are other goals, too, like not limiting the syntax of the EAPI assignment. I was just trying to think up something that addresses them all. In any case, yeah, it would crash and burn if someone synced his tree with an ancient version of portage. But so would the comment solution. If you want to fix that, we either have to rename everything (and hope we get it right this time) or reconsider GLEP 55.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 11:29, Michał Górny wrote:
>
> What if bash starts to parse the script completely and barfs at 'syntax
> error' before it starts executing stuff?
>
It doesn't parse the script completely, it executes line-by-line, so we
can bail out early.
This returns 1:
exit 1
QWE*$)@#$%IT@$KTRGV{PO#J$%$M@#$_)TVI!%K@B)$YJMV$%())@K#@)
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 12:11, Ulrich Mueller wrote: >>>>>> On Fri, 09 Mar 2012, Michael Orlitzky wrote: > >>> What if bash starts to parse the script completely and barfs at >>> 'syntax error' before it starts executing stuff? > >> It doesn't parse the script completely, it executes line-by-line, so >> we can bail out early. > > How can you tell that this behaviour won't be changed in a future bash > version? > Who's to say that in the future my computer won't be made out of delicious ice cream, eliminating the need for EAPIs entirely? Chances are, this would break thousands of scripts, so we hope they wouldn't do it. If it does happen, we either deal with it then, or don't upgrade to that version of bash -- the same as we would do with any other massive breaking change. At any rate, I'm now convinced that we all want GLEP 55, but with a different name.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 12:47, Zac Medico wrote: > > Ulrich is talking about extensions which require a newer version of > bash. These kinds of extensions are quite common and don't cause > "massive breaking" because people simply have to upgrade bash in order > to use the new extensions, and their old scripts continue to run because > the new extensions don't interfere with backward compatibility. > > Your eapi() function proposal is especially fragile in this context > because it assumes that the installed version of bash will be able to > execute a script that may target a newer version of bash. This is a > special case that is typically not a problem, although it is a major > problem under the specific conditions that your eapi() function approach > induces. Well, you wouldn't need to execute the script targeting a newer version of bash. You would need to source it, which involves maybe setting EAPI=5, and then calling the 'eapi' function which will immediately exit. The new features aren't a problem because you never get to them. (If you try to use some new bash extension to compute your EAPI value, well, you shouldn't have done that.) > Anyway, lets focus on our main goal, which is to decide on a way to > obtain the EAPI _without_ sourcing the ebuild. Agreed. I'm forced to agree with Ciaran: can we just ignore the previous council's decision, and reconsider the merits of GLEP 55?
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 13:02, James Broadhead wrote: > On 9 March 2012 17:31, Michael Orlitzky wrote: >> At any rate, I'm now convinced that we all want GLEP 55, but with a >> different name. > > I think that moving the data to the filename is probably a better > approach than semi- or repeat parsing, but I prefer preserving the > .ebuild extension, and think that eapi should be specified similarly > to ebuild revision, as a suffix. for instance: > > app-foo/bar-1.0.0-r1.ebuild # EAPI0 (or the highest EAPI prior to the > new schema) > app-foo/bar-1.0.0-r1-e1.ebuild > app-foo/bar-1.0.0-r1-e99.ebuild > One of the benefits of GLEP 55 naming is that old package managers won't try to parse them. So, for example, if we put new features in, app-foo/bar-1.0.0.ebuild-5 portage from 2003 won't try to source it.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/09/12 13:56, Zac Medico wrote: > On 03/09/2012 10:33 AM, Michael Orlitzky wrote: >> On 03/09/12 13:02, James Broadhead wrote: >>> On 9 March 2012 17:31, Michael Orlitzky wrote: >>>> At any rate, I'm now convinced that we all want GLEP 55, but with a >>>> different name. >>> >>> I think that moving the data to the filename is probably a better >>> approach than semi- or repeat parsing, but I prefer preserving the >>> .ebuild extension, and think that eapi should be specified similarly >>> to ebuild revision, as a suffix. for instance: >>> >>> app-foo/bar-1.0.0-r1.ebuild # EAPI0 (or the highest EAPI prior to the >>> new schema) >>> app-foo/bar-1.0.0-r1-e1.ebuild >>> app-foo/bar-1.0.0-r1-e99.ebuild >>> >> >> One of the benefits of GLEP 55 naming is that old package managers won't >> try to parse them. So, for example, if we put new features in, >> >> app-foo/bar-1.0.0.ebuild-5 >> >> portage from 2003 won't try to source it. > > Every software product has an end of life. I think if a system hasn't > been updated in the last 2 years or so, then it's fair to assume that it > will never be updated. So, all relevant versions of portage should > simply show a warning message if the encounter an ebuild name such as > "app-foo/bar-1.0.0-r1-e99.ebuild". I was just repeating your point against the eapi function =) And there is a non-zero benefit to it, I've had to rescue systems that haven't seen an update in years. The best reason I can think of for using ebuild-EAPI is simply semantic. The basename of the ebuild refers to the package, the extension decides what interprets it. That is at least consistent with every other file extension.
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/12/12 13:12, Ciaran McCreesh wrote: > On Mon, 12 Mar 2012 18:05:46 +0100 > Ulrich Mueller wrote: >> See above, even if we should ever move away from bash, GLEP 55 is >> still not needed. > > ...but we might as well go with GLEP 55 anyway, since GLEP 55 > definitely works, whereas other solutions might work so long as we > don't do something unexpected. > > This whole thing is just an exercise in trying to find excuses not to > use GLEP 55. > Not understanding any of the politics involved, what are the technical arguments against it?
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/13/2012 08:29 PM, Walter Dnes wrote: I'm answering Ciaran's and Brian's posts together, because the answer is the same for both... namely, we need a 2-pass processor, regardless of whether it's bash/perl/python/whatever. Pass 1 checks for syntax errors and retrieves "special" variables, answering Ciaran's concern. Today, it's EAPI. In future, there may be others. Pass 2 does the build, assuming no errors detected in pass 1. Problem is, the only thing that can tell if there's a bash syntax error is bash itself.
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/13/2012 10:05 PM, Zac Medico wrote: On 03/13/2012 06:42 PM, Brian Harring wrote: Leaving it such that the PM has to enforce things like "don't have multiple EAPI assignments" means by default, one of them isn't going to... leading to the ebuilds breaking... specifically the common case being the ebuild becoming acclimated to some quirk of portage. My intention is for PMS to specify the search algorithm that's used to probe the EAPI, and also for it to specify that package managers must treat an ebuild as invalid if the probed EAPI is not identical to the one that's obtained from bash. If all package managers adhere strictly to these two requirements, then we won't have any incompatibilities between package managers here. Someone should really throw up a table on wiki.g.o with a comparison of the proposed methods. IIRC, the pros/cons of this in contrast to GLEP 55 are something like, Pro: * We don't need to change the filename, and "ebuild" is nice * GLEP 55 pissed people off, and was already rejected * Some people think the EAPI rightfully belongs in the ebuild Cons: * New features can't be implemented immediately because PMs have to catch up first. * Slight performance hit * Old package managers on out-of-date systems will barf on it * It involves using a magic identifier, e.g. a comment. Magic is bad, and the fact that messing with a comment can break your PM is counter-intuitive. * Some people think the EAPI rightfully belongs in the filename and the last one is worth the most points to everyone anyway.
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/13/2012 10:36 PM, Zac Medico wrote: On 03/13/2012 07:23 PM, Michael Orlitzky wrote: Someone should really throw up a table on wiki.g.o with a comparison of the proposed methods. We've got one already: http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms *facepalm*
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 14:56, Zac Medico wrote: > On 03/14/2012 11:36 AM, Maxim Kammerer wrote: >> On Wed, Mar 14, 2012 at 19:58, Matthew Summers >> wrote: >>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite >>> nice to have a minimal recovery env in case mounting fails, etc, etc, >>> etc. >> >> There is nothing bad about initramfs. I think that you are misreading >> the arguments above. > > Whatever the arguments may be, the whole discussion boils down to the > fact that the only people who seem to have a "problem" are those that > have a separate /usr partition and simultaneously refuse to use an > initramfs. People just don't like change for the sake of change, and haven't been shown any benefits yet. I don't have a separate /usr anywhere, but if I did, I would have to rebuild and test a good number of custom kernels that would eventually need to wind up on production servers. It would take a least a day's worth of work, not to mention staying late to make the switch overnight. If you can offer me something cool for it, great; but at the moment people are being offered "it will work the same as it did yesterday," which sucks, because it works that way now. Sure, there will be improvements in the future, but it can feel a lot like treading water sometimes.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/16/12 11:18, Greg KH wrote: > > At least find a package that people use :) > www-client/httrack?
Re: [gentoo-dev] If anyone is intrested in helping around with Xfce...
On 03/22/2012 03:29 AM, Samuli Suominen wrote:
On 03/22/2012 09:25 AM, Samuli Suominen wrote:
If anyone is intrested in helping around with Xfce we have 2 bigger
tasks on going:
1) Pass --libexecdir="${EPREFIX}" to all plugins installing to
/usr/libexec/xfce4/ as opposed to /usr/lib/xfce4/
Typing error.
inherit multilib xfconf
--libexecdir="${EPREFIX}"/usr/$(get_libdir)
I tested this, works fine. Is there a better way to fix it within the
package, though?
diff --git a/xfce-extra/xfce4-hdaps/xfce4-hdaps-0.0.7.ebuild
b/xfce-extra/xfce4$
index f987178..6ac70b6 100644
--- a/xfce-extra/xfce4-hdaps/xfce4-hdaps-0.0.7.ebuild
+++ b/xfce-extra/xfce4-hdaps/xfce4-hdaps-0.0.7.ebuild
@@ -29,6 +29,7 @@ DEPEND="${COMMON_DEPEND}
pkg_setup() {
XFCONF=(
--disable-option-checking
+ --libexecdir="${EPREFIX}"/usr/$(get_libdir)
$(xfconf_use_debug)
)
Re: [gentoo-dev] New category for (libre)office extensions: office-ext ?
On 05/05/12 14:40, Andreas K. Huettel wrote: > > Hiya, > > there's a growing culture of libreoffice extensions, and (with the help of an > eclass prepared by scarabeus) it would be nice to get some of them into the > portage tree. Now we have to decide where to put them. > > Suggestion: new category office-ext > > What do you think? No preference myself, but we already have e.g. app-emacs and www-apache which (I guess?) reflect the fact that emacs lies under app-foo and apache under www-bar. That would suggest app-libreoffice?
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
How about introducing e.g. FEATURES="nouserpriv", and make the current userpriv behavior the default? The migration might be a bit more confusing, but it allows portage to gradually adopt better stuff without having FEATURES="everything under the sun".
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
On 05/29/12 15:58, Mike Gilbert wrote: > On Tue, May 29, 2012 at 3:46 PM, Michael Orlitzky > wrote: >> How about introducing e.g. FEATURES="nouserpriv", and make the current >> userpriv behavior the default? >> > > Portage currently defaults to running the build process as root. The > entire point of this thread is that Zac wants to change the default to > build as the portage user (FEATURES="userpriv" in make.globals). > Right, I was just offering a way to change the default behavior without adding another value to the FEATURES variable, which seems to be hasufell's objection.
Re: [gentoo-dev] Should packages auto-eselect alternative implementation on removal?
On 05/30/2012 05:23 PM, Mike Frysinger wrote: > On Wednesday 30 May 2012 13:01:24 Michał Górny wrote: >> This issue was given my attention through bug 418217 [1]. Long >> story short -- there are applications which call pager >> implicitly. Those are git & systemd. They don't actually require >> any pager being installed; however, if $PAGER is set they use >> it. > > then isn't it a bug they aren't depending on virtual/pager ? Git works fine without a pager. It just won't work if $PAGER is set to something invalid.
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
On 05/31/12 16:09, Michał Górny wrote: > On Thu, 31 May 2012 15:58:43 -0400 > Rich Freeman wrote: > >> On Thu, May 31, 2012 at 3:33 PM, Michał Górny >> wrote: >>> What would git signing work with rebased commits? Would all of them >>> have to be signed once again? >>> >> >> The whole point of rebasing is to throw away history (which is either >> good or bad based on your perspective). >> >> So, if 14 devs spend 3 years and 2000 commits working on something in >> a branch, and I commit it to master using a rebase, then all you'll >> see in the master history is that rich0 committed 20k lines of code to >> master on May 31st, and that would be signed by me. >> >> I think that rebasing before merging is a pretty typical workflow >> anyway - when you submit a patch to Linus, he doesn't really care that >> you spent six months tweaking it - he just is getting a big blob of >> code that either works or doesn't. Does all that sub-history really >> matter? You could always push the branch to the repository if you >> wanted to keep it on the side. > > That sounds like a pretty poor workflow to me. If I tweak something for > 3 years, I'm likely to have a larger set of logically organized commits. > I'm not saying it's unlikely I'm going to rebase fixes for obvious > mistakes but putting everything onto one blob just makes the changes > harder to read and less maintainable. > > For example, if I first create a basic function and then add additional > options to it, I'm likely to keep those as separate commits. If one of > the changes was a really bad idea, I'd like to revert the appropriate > commit rather than removing all traces of it by hand and mistakenly > introducing even worse breakage. > That isn't what rebasing does, unless you do an interactive rebase and decide to squash the commits. The usual use case for a rebase is just to avoid the ugly merge commit. For example, 1. I clone your portage tree 2. I start making commits locally 3. You add a new package 4. I try to push my changes to you Step 4 doesn't work because your repo has changed. I can either, a) pull from you again (merge) b) pull with a rebase And then I should be able to push to you, assuming there were no conflicts. The merge option works fine but generates an ugly merge commit. The rebase takes our two histories and combines them into a nice linear history. In this case, a rebase would (essentially) take all of my commits and stick them on top of your "new package" commit. Afterwards, it looks like there's a nice linear history: you added a package, and then I did a bunch of other stuff. All of the commits are there. Since that history is linear and it looks like just a bunch of stuff on top of your existing tree, I can push it to you without problems. The only downside to the rebase is that it modifies my local history. So, if somebody cloned *my* repo in the middle of that, they could get screwed up.
Re: [gentoo-dev] [PATCH] prune_libtool_files(): go into .a removal only when .a exists.
On 06/15/12 09:32, Michał Górny wrote:
> It is a little confusing when the function reports .a removal when no
> such file exists. Also, explain why the file is removed.
Why keep the "-f"?
> ---
> eclass/eutils.eclass |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
> index 116f7bc..931d97d 100644
> --- a/eclass/eutils.eclass
> +++ b/eclass/eutils.eclass
> @@ -1438,8 +1438,10 @@ prune_libtool_files() {
>
> # Remove static libs we're not supposed to link against.
> if grep -q '^shouldnotlink=yes$' "${f}"; then
> - einfo "Removing unnecessary ${archivefile#${D%/}}"
> - rm -f "${archivefile}"
> + if [[ -f ${archivefile} ]]; then
> + einfo "Removing unnecessary
> ${archivefile#${D%/}} (static plugin)"
> + rm -f "${archivefile}"
> + fi
>
> # The .la file may be used by a module loader, so avoid
> removing it
> # unless explicitly requested.
Re: [gentoo-dev] news item: upgrading to postfix-2.9
On 07/17/12 07:21, Eray Aslan wrote: > On 07/17/2012 02:00 PM, Dirkjan Ochtman wrote: >> It may be a small issue, but since the potential pain is quite large, > > Yes, that's the idea. > >> since postfix config file changes are usually >> pretty hard to review for merges. > > Hmm, that's a failure on our part. >=postfix-2.9 ebuilds is better in > this regard. Ideally, only readme_directory and html_directory settings > should come up in dispatch.conf. If you are still having problems > during upgrades in postfix-2.9.x versions, please let me know. > After changing these for years, I finally realized that the defaults are correct: # postconf -d readme_directory html_directory readme_directory = /usr/share/doc/postfix-2.8.9/readme html_directory = /usr/share/doc/postfix-2.8.9/html Do we really need to include them in main.cf?
Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
On 07/24/12 09:21, Ian Stakenvicius wrote: > > Given that this just affects new installs, is a news item (via > portage) a particularly good way to inform everyone? I was wondering > if it'd make more sense to notify on the website and *definitely* > change the Handbook... > > ..and maybe include an '/etc/make.conf.moved' in the stage files for > the next 6 months which says the above? I think a news item is reasonable here (in addition to the above). Most users don't know about the move from /etc/make.conf to /etc/portage/make.conf. After this change, there will be a gradually-increasing need to know that a switch took place. 1) To a first approximation, nobody reads the documentation. 2) /etc/portage/make.conf overrides the traditional location. If you have both, it will lead to subtle problems. After this change, new users won't even know that /etc/make.conf used to exist, so there's a possibility of two admins stepping on each others' feet. 3) When providing help on forums and mailing lists, existing users will need to know that the location was switched. 4) There are problems I haven't thought of. Better safe than sorry.
Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
On 07/24/12 14:52, Rick "Zero_Chaos" Farina wrote: > > This is a big enough change that it will throw users who do not know, > and my first impression of /etc/make.conf et all missing on a new stage > is "file a bug report for a broken stage and assign it to those morons > in releng". (please note the comic exaggeration and not a disrespect). And mine would be to assume that we stopped shipping make.conf, and just fill in the missing details in /etc/make.conf before building the system. Everything would look like it's working, but portage isn't using the make.conf that I think it is.
Re: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds
On 07/26/12 14:26, Rich Freeman wrote: > I've been messing around with namespaces and some of what systemd has > been doing with them, and I have an idea for a portage feature. > > But before doing a brain dump of ideas, how useful would it be to have > a FEATURE for portage to do a limited-visibility build? That is, the > build would be run in an environment where the root filesystem appears > to contain everything in a DEPEND (including @system currently) and > nothing else? It might be useful both in development/testing, and > also in production use (not sure how performance would work in the > real world - I was able in a script to get it to build an enviornment > in a few seconds for a few packages). The Cabal build system for Haskell packages does this and it's extremely useful. It prevents me from forgetting dependencies like 'directory', 'time', etc. that I use without thinking. runghc Setup.hs build Building lwn-epub-0.0... Preprocessing executable 'lwn-epub' for lwn-epub-0.0... src/LWN/Article.hs:12:8: Could not find module `System.Directory' It is a member of the hidden package `directory-1.1.0.2'. Perhaps you need to add `directory' to the build-depends in your .cabal file. Use -v to see a list of the files searched for.
Re: [gentoo-dev] UTF-8 locale by default
On 07/27/12 16:16, Aaron W. Swenson wrote: > > No user will be happy with whatever we decide to use as a default. The defaults should be what's best for the most people, with a bias towards safety. Why don't we just take a survey and choose the most common utf8 response?
Re: [gentoo-dev] UTF-8 locale by default
On 07/30/12 10:41, Michał Górny wrote: > On Mon, 30 Jul 2012 10:35:36 -0400 > Michael Orlitzky wrote: > >> On 07/27/12 16:16, Aaron W. Swenson wrote: >>> >>> No user will be happy with whatever we decide to use as a default. >> >> The defaults should be what's best for the most people, with a bias >> towards safety. Why don't we just take a survey and choose the most >> common utf8 response? > > How can you take a survey like that? How will you ensure it actually > hits the majority? How will you define the majority? > Considering that the alternative is to force everyone to change it manually, you can do it however you want and it'll be an improvement. 1) Create a webpage with a bunch of options, count the results 2) Ask the g.o mailing lists, count responses manually 3) Use google docs like the website survey that went out a few days ago It won't hit everyone, but no survey ever does. As long as you get a large enough unbiased sample, it doesn't matter. And anything would be an improvement, so it doesn't matter anyway.
Re: [gentoo-dev] UTF-8 locale by default
On 07/30/12 12:28, Michał Górny wrote: > > My point here is that you want the thing to change. So you first try to > convince people here to change. We practically did a small survey here > and in the result we didn't agree on doing the change. > > So you're saying we should do another survey on another group, hoping > that this time the result will be on your side. We didn't do a survey, we asked, "Is there a reason for not using at least en_US.UTF-8 as a "sane" default value?" Unsurprisingly, the responses contained reasons for not using en_US.UTF-8 as the default. Don't take my original reply out of context, I don't actually care what we have as the default. > > It depends on who the 'unbiased sample' is. Are you interested only in > opinion of Gentoo users who visit the website? Who sync once a day? > Once a week? Who follow Gentoo Planet? Who participate in the forums? > > We can create the survey and announce it everywhere. But it still won't > catch many old-time Gentoo users who can actually have something > opposite to say. It won't be unbiased. The technical objection to C.UTF-8 is that it's non-standard, Ok. What are the technical objections to LC_CTYPE=en_US.UTF-8? If the alternatives are all improvements, the statistics are irrelevant.
Re: [gentoo-dev] UTF-8 locale by default
On 07/30/12 15:02, Walter Dnes wrote: > Would forcing UTF-8 cause problems for packages that expect > specific ISO encodings in X fonts? Not that I know of (and setting a default wouldn't force anything). xfreecell's readme states "Make sure there is a font named 7x14" and another thread mentions that this is provided by media-fonts/font-misc-misc so that sounds like a bug in the ebuild to me.
Re: [gentoo-dev] UTF-8 locale by default
On 08/01/12 16:18, Andreas K. Huettel wrote: > >> >> If it turns out that C or POSIX is the most common response, we should >> then default the locale to en_US.UTF-8 if we really want to default to >> a UTF-8 setting. The reason being it makes sense to have the default >> locale set to the country of origin, which in our case is the United >> States. >> > > Given the number of Gentoo devs (especially on the desktop side where this > matters most) from other parts of the world, that's not really a valid > argument. In particular in cases as e.g. "Paper size setting", where > basically > US stubbornness stands against the rest of the planet. > Every locale is wrong for somebody; the idea was that by taking a survey, you could make it wrong for the least amount of people (by default). If the majority of users use a stupid paper size, the best default is still whatever they use regardless of any personal preferences.
Re: [gentoo-dev] EAPI usage
On 09/02/2012 09:46 AM, Rich Freeman wrote: > On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel > wrote: >> What I dont actually understand at all is why bumping the EAPI should be so >> complicated or involved that it even deserves so much resistance... > > Ok, it REALLY annoys me when people pull out this kind of a line > in an argument... If it isn't all that complicated or involved and it > just makes so much sense, then why do we bother to waste time asking > for it to be made policy, since obviously everybody will just do it > anyway... > > Believe it or not, people who take up an opposing side in a debate > don't ALWAYS do it because they're simply dumber than you. That is, > unless they're arguing with me... :) > I think everyone would be happier if all ebuilds in the tree were EAPI4. On the other hand, Rich is right that making this a policy will have the opposite of the intended effect: developers just won't fix bugs in EAPI<4 ebuilds when they don't have time to do the EAPI bump (one could easily spend a few hours on this). As a compromise, it could be made policy that "bump to EAPI=foo" bugs are valid. If someone would benefit from such a bump, he can file a bug and know that it won't be closed WONTFIX. On the other hand, the dev is under no more pressure than usual to do the bump.
Re: [gentoo-dev] EAPI usage
On 09/04/2012 05:06 PM, Brian Harring wrote: >> >> As a compromise, it could be made policy that "bump to EAPI=foo" bugs >> are valid. If someone would benefit from such a bump, he can file a bug >> and know that it won't be closed WONTFIX. On the other hand, the dev is >> under no more pressure than usual to do the bump. > > If you attach a patch and have done the legwork, sure. > > If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's > noise and it's annoying. EAPI bump requests for pkgs that need to > move forward so an eclass can be cleaned up/moved forward, sure, but > arbitrary "please go bump xyz" without a specific reason (and/or > legwork done if not) isn't helpful. Kind of equivalent to zero-day > bump requests in my view in terms of usefulness. Except this is what we have now, and isn't a compromise at all.
Re: [gentoo-dev] EAPI usage
On 09/05/2012 12:15 PM, Mike Gilbert wrote: > On Tue, Sep 4, 2012 at 9:03 PM, Michael Orlitzky wrote: >> On 09/04/2012 05:06 PM, Brian Harring wrote: >>>> >>>> As a compromise, it could be made policy that "bump to EAPI=foo" bugs >>>> are valid. If someone would benefit from such a bump, he can file a bug >>>> and know that it won't be closed WONTFIX. On the other hand, the dev is >>>> under no more pressure than usual to do the bump. >>> >>> If you attach a patch and have done the legwork, sure. >>> >>> If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's >>> noise and it's annoying. EAPI bump requests for pkgs that need to >>> move forward so an eclass can be cleaned up/moved forward, sure, but >>> arbitrary "please go bump xyz" without a specific reason (and/or >>> legwork done if not) isn't helpful. Kind of equivalent to zero-day >>> bump requests in my view in terms of usefulness. >> >> Except this is what we have now, and isn't a compromise at all. >> > > What use is a bug report requesting an EAPI bump for no reason? There > is no sense in "compromising" and creating such a policy if nobody > actually benefits from it. > If there's really no reason, why would anyone bother to file a bug for it? It's better for developers than the must-bump policy, and better for users than what we have now.
Re: [gentoo-dev] EAPI usage
On 09/05/2012 05:29 PM, Brian Harring wrote: > > Yes, I stated it because I view it as useful/sane. > >> and isn't a compromise at all. > > I think you're mistaken in assuming a compromise is the required > outcome of this. Given the choice between something productive, and > something not productive, you don't choose the quasi-productive > solution. >From a developer's perspective, it's obviously better to be able to do whatever you want. But for users it'd be nice to be able to request a bump to EAPI5 and not get told to buzz off. Some people are unhappy with the current situation or this thread wouldn't exist. A good compromise should make everyone just a little bit unhappy =)
Re: [gentoo-dev] Unified DEPENDENCIES concept
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.
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 > 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] Re: example conversion of gentoo-x86 current deps to unified dependencies
On 09/19/2012 06:59 AM, Duncan wrote: > Ben de Groot posted on Wed, 19 Sep 2012 12:22:06 +0800 as excerpted: > >> On 16 September 2012 21:15, Brian Harring wrote: > >>> So... basically, people are already doing this manually with their own >>> intermediate vars. >> >> And this works fine, so it doesn't warrant a cosmetic change. > > @ferringb: > > yngwin has a point that I've not seen addressed. > > What /is/ wrong with the whole CDEPEND intermediate var idea? It seems > to work and /I/ don't know of any problems with it (and it would appear, > neither does yngwin), yet you talk about it as if there's something wrong > with it. > > And while we're at it, do DEPEND="$RDEPEND ..." style solutions have the > same problems (or lack thereof)? The problem appears as we introduce more DEPEND variables (which is what prompted the proposal, IIRC). If we have ADEPEND, BDEPEND, CDEPEND, and DDEPEND, and there's only some (i.e. not total) sharing going on then the COMMON_DEPEND pattern starts to fall apart. You potentially need, AB_DEPEND AC_DEPEND AD_DEPEND BC_DEPEND BD_DEPEND CD_DEPEND ABC_DEPEND ABD_DEPEND ACD_DEPEND BCD_DEPEND ABCD_DEPEND (COMMON_DEPEND) This obviously gets worse as more DEPEND vars are introduced.
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
On 10/31/2012 10:05 AM, Rich Freeman wrote: > On Wed, Oct 31, 2012 at 9:18 AM, wrote: >> Maybe you should remember that non-devs simply /aren't allowed/ to >> assign bugs correctly... >> >> And if you look closer into these bugs, you might discover that jer >> instructed this guy to file separate bugs. (see #440178) >> > > Fair points, and clearly this wasn't malicious. I think we still want > to find a better solution than logging dozens of bugs for the > wranglers. Perhaps where there is a need we can give elevated privs > in bugzilla to those running scripts who understand what they're > doing. Or non-devs could ask a dev to run the script for them after > review. This would be nice anyway. I'm generally capable of reading metadata.xml and determining whether or not to tag my bugs with e.g. STABLEREQ. One less bug to wrangle.
Re: [gentoo-dev] Re: Re: Maintainer needed: dev-libs/icu
On 11/05/2012 10:39 AM, Diego Elio Pettenò wrote: > On 05/11/2012 07:31, Steven J. Long wrote: >> Are you really missing the fact that by testing someone's overlay, the >> package >> would by definition not be in the tree, and you wouldn't have to file any >> bugs >> at all, just (automatically) email the output back to the overlay developer? > > Which means I wouldn't be filing bugs for the problems with the > _existing_ packages that are in tree, which is what the users actually > _use_ by default. > > If the users are forced to use overlays to get working packages, then I > feel I'm perfectly right with screaming at the developers who are using > overlays for development because they leave users in a sorry state. Do other people agree that something should be done about this? I see two reasons to prefer overlays to the main tree: 1) Over time, unstable has become too stable (I know, I know). People expect things to work, and nobody wants to break working systems by committing works-in-progress to ~arch. 2) CVS sucks; git is much more fun to use. It also makes user contributions easier. The first I think could be helped with a third level of stability, say, !arch, which stands for it-aint-gonna-fuckin-work-on-'arch'. Devs could pile anything that's eventually headed for the tree here, and catch conflicts early. I'm not entirely joking about the name -- it would have to be clear that this is a staging area and no one should use it in production. But this is a big change. The second will be helped by the git transition, but what about the overlay situation now? For work/school, at a minimum, I need, * sunrise[1] * gentoo-haskell[2] * science[3] And nice-to-have: * emacs[4] All of these are already in git, and run by developers. Why not have them all (and the other dev-run git overlays) in the same repo? Just give everyone commit access. Then when you're ready to push something to the tree, you already know that it won't break anything. [1] http://git.overlays.gentoo.org/gitweb/?p=proj/sunrise-reviewed.git [2] https://github.com/gentoo-haskell/gentoo-haskell [3] http://git.overlays.gentoo.org/gitweb/?p=proj/sci.git [4] http://git.overlays.gentoo.org/gitweb/?p=proj/emacs.git
Re: [gentoo-dev] Re: Re: Maintainer needed: dev-libs/icu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/05/2012 12:15 PM, Ian Stakenvicius wrote: > On 05/11/12 12:00 PM, Michael Orlitzky wrote: > >> 1) Over time, unstable has become too stable (I know, I know). >> People expect things to work, and nobody wants to break working >> systems by committing works-in-progress to ~arch. > > > We have p.mask for that, though, so dev's could get in the habit of > committing and hard-masking things more, rather than using > overlays. > > >> The first I think could be helped with a third level of >> stability, say, !arch, which stands for >> it-aint-gonna-fuckin-work-on-'arch'. > > well, per ~arch p.mask is possible here, as is removing keywords. > For things that definitely don't work we also have '-arch' > (usually used as -*) but that tends to be more permanent. > > > Devs could >> pile anything that's eventually headed for the tree here, and >> catch conflicts early. I'm not entirely joking about the name -- >> it would have to be clear that this is a staging area and no one >> should use it in production. But this is a big change. > > - From p.mask'ing? *shrug* > Being hard masked is a little bit stronger than what I had in mind. I was thinking, "no known problems, but it hasn't been tested thoroughly." Users with a death wish could run it, and it might work. That would leave package.mask for known brokenness: build failures, security issues, etc. But anyway, I replied where I did because it was pointed out that not enough people are using package.mask to test -- they're using overlays instead, and that makes life difficult for end users. I'd just like to see more stuff wind up in the tree, or at least in one big (git) overlay to catch conflicts. If everything in those overlays was in the tree but masked, that'd be awesome. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQl/gsAAoJEBxJck0inpOiYB4P/14RM6RwtS1pW9xducpGS2qW 5wIHhW+5wNK9FNSpnMU3knOaMxwQTlVQt6BXHhttNKPD2v2SsnESyd88PA1ht0+8 NTPlrbKO9dyLyRfU+hxKGGbET45x7dLT2zDe0skc1dF78A9T5QDpwKlDfQSctxzT rTZ3HYa/Ff7PCvb9FzEWlr3KqdC+ictju2R+F7CjZKOjNUgPvPEIBOEP7vRYYJSe 7aK8cCN2yuKcK/ykaA4qiiRM18oRljG/5gEhvZ98JoVSiOwIr+RZeuVxw+XGxCY8 6+XntBjPPi/bkvSVVExWTpPAP+he75Zm/9vvrVDR3log6nLRx7pW0EIfzcBBVMc5 LujBTIK0EJFjtvELIPdq5HD85jgC5rNn3Kv7xGvp6K0VVWzegZ2RgKsG56qkITC3 2KYq4qN3FLaFM08NKdUfE8FRPd9M+jYowG6etTdU++46p8Al/qu/lV4c5frWzGik Q0EHOpOk94M2OeWEoxauozUyy5Z2oBISgaVx8HWrS/qHgEnvuUe2g7EA9XbIpFHI rIF1oRYBrh/9/SX4R6BSisNx57NXMcRBODezEPBYuQ5fY0kWcvSnJAx2SKzRBanX +09R9sxDOGnczUHgfNwOMDRbTIUUnQEucIVewYSe7C/DKBtYlyStuY6lm5ytQ46n 6JDD46PWiKfewYE5c+yj =nb95 -END PGP SIGNATURE-
Re: [gentoo-dev] XFCE needs help with maintaince of xfce-extra/ (at least temporary)
On 11/14/2012 06:17 AM, Peter Stuge wrote: > Samuli Suominen wrote: >> so unless you are willing to go that far as introducing yourself at the >> xfce devel mailing list and accepting the mantle of upstream of them, we >> are really stuck at this distribution level patching just like others > > That makes no sense to me. If you (not you specifically, the generic > 'you') have patches then you push them upstream. > > 0 distribution patches would only be unrealistic because of some > refusal to work with upstream. > > If you are doing some patching of XFCE then I think there is no > difference as far as the code goes between doing it in a gentoo > repository and doing it in the upstream repository. > I think you're reading past what he said. He needs help submitting things upstream, so that they can be added to portage. There are a lot of xfce extras which in reality are unmaintained. Other distributions have patches for them to make them forward-compatible. The right thing to do, as you pointed out, is submit these upstream. Samuli wants help doing that. Once they're upstream (at least in git/bugzilla), those patches can be added to portage. Or if anyone takes over maintenance of the package, merged upstream. Having someone maintain the extras would of course be preferable, but this is better than rolling our own patches independent of the other distros.
Re: [gentoo-dev] Packages up for grabs due apache herd removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/2012 02:43 PM, Pacho Ramos wrote: > After discussing it at: > http://www.gossamer-threads.com/lists/gentoo/dev/262834 > > ... > Apache itself is in need of some attention these days. The ChangeLog shows only Patrick committing in the last six months, which -- correct me if I'm wrong -- is just part of his "if there's a bug I'm gonna fix it" plan (thanks). Plenty of issues, especially with the 2.4 series, have gone unaddressed. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQtbyFAAoJEBxJck0inpOieE0QAIQGStXs0M05a9QaG8goJup7 0/ybh865zKMwMeevTxwpoS4ITqiaPEW+Fcw4bKcIFY58YutcGwAq0J1/uFWpapbG 2/RvTXM7klm+7ACqTmDdo3P9K1woBJOq3jk/duPno1nmT3rT3c0JoeKXrGvPuOFs VM/U4x4l6ofIxq/SfYy2Wq5//soyzUM4/xiqNBsiHIYLKAHDoQ2mD49zV7lgR9cJ R5PouJ4E13NbNzICoJsex4G/R5sIywqs5ILfeQEmsZ34O+VPqJMxf+wfjd/c0gwh KVF9DyVtOJ+nmKeZD5zSxcgRrZW01TWumzlB1qlMpSTw1/9+X0yeZUn6gnwQSdlr YYPRXDLecD1VZtsDYkJri8XiQb2+ahWZNsYhPgSGNedHvcOSOvadtWZ65sTHaqaT CsmaUgxbF1JpAq0R4KAuukonVODqk3XiKPY/ViFC3pW7AtDvjYFG6C8en0Yvxwdl YfHASCFqmi6Of8iX8IM9jmvXkzPB0y1RBIHAMpYZtl++gT9iXs2Ea5U/2jkCg2rT Sk13CDB2eghIFkdrNhG67fNlKDQm+Wx9H71iqJliJOxeTjhq58EmmyaLrOrGpAIK 2bKKeIq6CfmQp74yWZkQ+a0fjCTy1RaGDAK+nW1OK2d9zK229rwM3b7Q/zu4xFJO Y0LMWEbSK1ww+RzUzGR5 =vTQU -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]
On 12/01/2012 09:48 PM, Duncan wrote: > Chí-Thanh Christopher Nguyễn posted on Sun, 02 Dec 2012 01:28:26 +0100 as > excerpted: > >> If this change is applied anyway, I suggest to at least produce a news >> item in order to not surprise users about the sudden loss of their >> openldap server. > > I wouldn't object to a news item. More information is good. > > > > However, hasn't it always been gentoo policy to *STRONGLY* encourage > users to run emerge --pretend/--ask and EXAMINE THE RESULTS for anything > unexpected, and resolve it in one way or another to "expected", before > going ahead? > > Thus, anyone suddenly losing their openldap server as a result of a > simple uncaught USE flag change, "gets to keep the pieces", as the saying > commonly goes. Gentoo has /always/ been about reasonable documentation > but has /never/ been about handholding. We've never been afraid to point > users who expect to be handheld or babysat to other distributions that > are a more appropriate match to their expectations. We should! This is just an excuse for shitty QA. These things have real consequences for real people. > So yes, a news item is reasonable as it's arguably part of that "good > documentation". But in general, there's something wrong if we're unduly > worrying about loss of functionality involving a USE flag change, or even > a simple USE flag default change, because equally as arguably, anyone not > catching such things with the --pretend/--ask they do BEFORE letting > things just run, and/or not following up accordingly, really should be > thinking about a distribution other than gentoo in the first place. > That's a fact that's not really practical to change at this point, both > because we haven't the manpower to do all the required handholding, and > because it would make gentoo into something it's not, and something it > was never intended to be. Paraphrasing Star Trek's Bones, that would be > "Gentoo, Jim, but not as we know it." > > > I beat my wife, is it her fault she gets beaten for choosing to be with me? Don't blame the victim. Handholding != making an effort not to screw up people's systems. Even with emerge --pretend, all I'm going to see is that the minimal flag switched from off to on by default. Which I'll interpret as meaning, "the minimal flag was changed so that openldap[minimal] today means what openldap[-minimal] did yesterday." Someone's going to reboot three months after this change and their whole office is going to be down while they try to figure out why they don't have an LDAP server. For even a small business, that could mean thousands of dollars. "Ha ha, you shouldn't have trusted me!" is not the appropriate response.
Re: [gentoo-dev] Re: [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]
On 12/01/2012 10:50 PM, Diego Elio Pettenò wrote: > On 01/12/2012 19:44, Michael Orlitzky wrote: >> Someone's going to reboot three months after this change and their whole >> office is going to be down while they try to figure out why they don't >> have an LDAP server. For even a small business, that could mean >> thousands of dollars. >> >> "Ha ha, you shouldn't have trusted me!" is not the appropriate response. > > Erm, it might not be an appropriate response but ... to not check what > is going on is not an appropriate way to conduct a business anyway. > The only way to know what's going on is to read the ebuild. And nobody has the time to do that for every default USE flag change, especially when you're managing multiple machines. In this case, USE="-minimal" is really USE="make_it_work_at_all", for anyone who installs openldap on purpose. > Especially not if you use a desktop profile on an LDAP server in > production ... > Maybe his boss isn't good with the terminal, and makes him install GNOME on the servers? Who knows. The profile name is just an arbitrary string associated with a set of defaults. People do weird things. This is not in itself proof that the admin is an idiot deserving of punishment. > Seriously, if that's a scenario that you find yourself into often .. you > should consider changing habits.. drastically. It's fun to condescend from time to time, but you shouldn't use yourself as the bar against which you measure everyone else. Up to a rounding error, everyone using Gentoo knows less about it than you do. They should be able to keep a system running, too. Anyway, I'm fine with the change as long as there's a news item. I just get annoyed with the "don't use Gentoo unless you like your stuff broken" attitude.
Re: [gentoo-dev] Re: [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]
On 12/01/2012 11:21 PM, Diego Elio Pettenò wrote: > On 01/12/2012 20:09, Michael Orlitzky wrote: >> The only way to know what's going on is to read the ebuild. And nobody >> has the time to do that for every default USE flag change, especially >> when you're managing multiple machines. >> >> In this case, USE="-minimal" is really USE="make_it_work_at_all", for >> anyone who installs openldap on purpose. > > Not really. Have you ever managed a network of multiple servers and > clients? It's extremely common to have USE=minimal on clients, and not > on servers, as that's what (most of the time) USE=minimal refers to. > I have, and I have no idea what USE=minimal usually refers to, because it differs wildly from package to package. I suspect most people know even less than I do. >> Maybe his boss isn't good with the terminal, and makes him install GNOME >> on the servers? Who knows. The profile name is just an arbitrary string >> associated with a set of defaults. People do weird things. This is not >> in itself proof that the admin is an idiot deserving of punishment. > > The profile name is not "just an arbitrary string" — it's a description. > If you don't read and understand a description as easy as "desktop", I > reserve the right to think you're an idiot. You can reserve the right of > thinking whatever you want about me, but my opinion still stands. > > I've had GNOME, or KDE, in many systems before that I wouldn't count as > "desktops" — you know how I handled them? Not going through the > "desktop" profile. Seriously. > Everyone on this list knows this, I suppose. But it's unrealistic to suppose that everyone does. >> Anyway, I'm fine with the change as long as there's a news item. I just >> get annoyed with the "don't use Gentoo unless you like your stuff >> broken" attitude. > > Guess what? I run Gentoo system in production and I also don't want them > to be broken. On the other hand I _do_ pay attention on what's going on, > especially because unless you install everything and the kitchen sink, > the updates on a weekly basis, for stable, are not that major. > > Sure, sometimes I have to look up what an USE flag does (and no, most of > the time I don't have to read the ebuild, we have descriptions in > metadata.xml for a reason!), but most of the time everything is > extremely easy to set up, and I don't usually get overthrown by > defaults' changes. > > Among others because for stuff I _really_ care about, I don't rely on > defaults but I set my flags explicitly (so yes I have a bunch of > packages that have -minimal in the package.use file). > $ cat /usr/portage/net-nds/openldap/metadata.xml And most people don't even know that metadata.xml exists. In my previous message, I said, "but you shouldn't use yourself as the bar against which you measure everyone else." You've countered with a list of things that you personally know and do, and therefore (as they've become commonplace to you) expect everyone else to know and do.
Re: [gentoo-dev] Re: [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]
On 12/02/2012 04:40 AM, Duncan wrote: > > As others have mentioned, equery u[ses] openldap . > Does nothing in this case. > Actually, I have a bug open at this very moment about a new ambiguous USE > flag, USE=fma, in the new sci-libs/fftw-3.3.3 ebuild. My bdver1 has > fma4, but not fma3. Does it apply? I checked the flag description, no > help. I checked the ebuild, it just use_enables fma. On the bug, I've > actually tested and found it works for my fma4 hardware, and I've posted > on the amd64 list asking someone with fma3 (probably an amd trinity apu > machine, at this point) to test it as well. > > https://bugs.gentoo.org/show_bug.cgi?id=445053 > > Hopefully we'll get a description that unambiguously states that it works > for both fma3 and fma4 out of that bug; either that or the flag will > change to presumably fma4, if it only works for fma4 (which I've tested) > and not fma3. > > Now obviously I don't expect most users to go to /that/ level. I'd > expect most users to simply leave the flag disabled if they're unsure. > But I WOULD expect most users to SEE the new flag, and investigate at > least far enough to see that they can simply leave it off if they don't > know whether their system has fma or not. The result might be a bit > slower, but it'll work, whereas if they don't have the hardware and turn > it on, things might not work. I think you have Stockholm syndrome. I've updated thousands of packages this month. I cannot do this for each one, and even if I could, there's a huge (unnecessary) opportunity cost to doing so. At the very least, my company has to pay my salary. If I were to spend a week reading the ebuilds for every update I do, that would also waste thousands of dollars of their money. I don't buy the false dichotomy that I should leave Gentoo rather than trust things not to break without warning. > Gentoo isn't for everyone, nor can it be and still be what we know as gentoo. This is really what I have a problem with, the openldap issue aside. There seems to be a vocal minority of hipsters who want Gentoo to remain "hard" so that they can use it ironically. The silent majority just want as many things to work as possible with as little effort as possible. This attitude not only gives Gentoo a bad reputation (see, for example, any distro thread on r/linux), but makes it hard to retain new users and contributors. Whenever something stupid breaks for no reason, there's always someone there to say "maybe Gentoo isn't for you." And some of those people leave. There isn't anything inherently difficult about Gentoo. Bad decisions by humans are what can make it hard to use[1], not anything fundamental to its nature. And the Gentoo that you know and love isn't going "soft" if it warns people that their LDAP servers might go away. [1] Please, no one take this as criticism. Things are in general wonderful.
Re: [gentoo-dev] Re: [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]
On 12/02/2012 11:19 AM, Diego Elio Pettenò wrote: > On 02/12/2012 08:02, Michael Orlitzky wrote: >> I think you have Stockholm syndrome. I've updated thousands of packages >> this month. I cannot do this for each one, and even if I could, there's >> a huge (unnecessary) opportunity cost to doing so. > > Sorry but there is no way you could have updated thousands of packages > _in stable_ at least not for a single system, this month (and I take it > as November, rather than December). > If this was a single system, I wouldn't be wasting your time. > I have four differently-configured servers in front of me, and none had > more than 51 packages installed on it during the course of November — > and this is with quite a few packages being updated more often (Icinga > and Munin) because I've been working on them. > > As I said in the other messages, I agree that we can do better – and > going with USE=server to me looks like going better – but I don't buy > the strawmen arguments that we have to cover for the totally unskilled > sysadmin that thinks he can run Gentoo in production and can't even see > what the updates are. So please drop it. > The USE=server solution is fine with me; the whole openldap thing was really tangential to the point I was trying to make. And for some reason it's not as fun to argue in the morning as it is at 2am, so thanks for working on it, it's dropped =)
[gentoo-dev] Guidelines for IUSE defaults
IUSE defaults are used in a few different ways: 1 To ensure that critical functionality is enabled. * Example: force the "unix" module for apache. 2 To avoid an unsatisfied REQUIRED_USE by default. * Example: having a non-empty RUBY_TARGETS by default. 3 To make Gentoo defaults the upstream defaults. * Example: right now the defaults for dev-lang/php build you a "normal" PHP installation. 4 To make the default build agree with the maintainer's personal preferences. * Example: enabling hpn in net-misc/openssh by default. We don't have a policy for how to use them, so we get all four in the tree. I don't think there are any downsides to #1. The downside to #2 is that the default choice may be wrong, but the benefit outweighs that. For a given package, the user either cares about the USE flags or he doesn't (if it's some deep dependency). Both cases turn out fine in #2. A bigger problem arises from #3 and #4: it's no longer simple to get a minimal system. When various USE flags default on at random, you get users doing things like USE="-*". We can tell them not to do that, because of the flags in #1, but in fact very few IUSE defaults are critical, and most of them are junk. The only way to turn off all the junk ones without a huge waste of time is USE="-*". Can we discourage IUSE defaults except for #1 and #2? I'm equally guilty of #3 and #4, but I now regret them. I would also like to see explanations in metadata.xml of why +flags are on by default.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/02/2017 10:06 AM, Kristian Fiskerstrand wrote: > On 02/02/2017 03:11 PM, Michael Orlitzky wrote: >> Can we discourage IUSE defaults except for #1 and #2? I'm equally guilty >> of #3 and #4, but I now regret them. I would also like to see >> explanations in metadata.xml of why +flags are on by default. > > This presumes that the goal is minimal system in all cases, rather than > a good user experience for inter alia a desktop system or a > server-system. If a user requires a minimal system for whatever reason > (s)he is likely more prepared to understand the choices than the average > user. > I'm not saying that we should have a minimal experience out-of-the-box, only that the base profile should result in an effectively-minimal set of USE flags. Adding IUSE defaults is essentially adding defaults to the base profile. Why does dev-java/icedtea try to pull in GTK (and thus X) on a headless server? That stuff belongs in a desktop profile, not in the base one. I don't think minimal should be our default, but it should be *possible*. It practically isn't so long as people mix uses #1, #3, and #4. I guess I would also be happy if we outlawed use #1 so that USE="-*" would be supported. In any case, we should document how to use them. Having them mean four different things causes confusion.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/02/2017 09:56 AM, Ian Stakenvicius wrote:
>
>> On Feb 2, 2017, at 9:11 AM, Michael Orlitzky
>> wrote:
>>
>> IUSE defaults are used in a few different ways:
>>
>> 1 To ensure that critical functionality is enabled.
>>
>> * Example: force the "unix" module for apache.
>>
>
> This is not what IUSE defaults are for, this should be done with
> package.use{,.stable}.{mask,force} in profiles. If functionality is
> critical then there (A) shouldn't be a use flag, or (B) shouldn't be
> a way for USE= in make.conf to disable it.
>
If we adopted this policy, then USE="-*" would no longer be guaranteed
to break the system. It does still ignore your profile defaults, though,
which presumably are important (e.g. for hardened). So we're still left
with no way for me to turn off everyone's pet USE flags and keep my
system working.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/02/2017 10:52 AM, Rich Freeman wrote: > On Thu, Feb 2, 2017 at 10:36 AM, Michael Orlitzky wrote: >> >> Why does dev-java/icedtea try to pull in GTK (and thus X) >> on a headless server? That stuff belongs in a desktop profile, not in >> the base one. > > The base profile isn't "headless server" - it is just generic. If this is how everyone is treating it, then we should at least document that fact... > The problem is that if you treat the base profile as "minimal" then > you lose the ability to maintain an upstream-default profile (unless > you end up with a huge package.use.force/mask file which IMO is the > wrong place to put stuff like this). Why would you need package.use.force/mask? The upstream defaults would build on top of the minimal base profile, in plain old package.use. In the profile is exactly where the upstream defaults belong in an "upstream defaults" profile. I think (base == minimal) is the simpler way to allow both possibilities.
Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults
On 02/02/2017 10:51 AM, William L. Thomson Jr. wrote: > On Thursday, February 2, 2017 10:36:51 AM EST Michael Orlitzky wrote: >> Why does dev-java/icedtea try to pull in GTK (and thus X) >> on a headless server? That stuff belongs in a desktop profile, not in >> the base one. > > In that specific case it cannot be avoided. Yes it can. I just have to waste my time unsetting the stupid USE flag that's on for no reason =P
Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults
On 02/02/2017 11:09 AM, James Le Cuirot wrote: > > Actually he's right. Java can obviously be used without GTK and that's > something we support but upstream hasn't taken the time to make it > possible to build without it. Apparently that isn't a trivial thing to > do. > > In my earlier mail, I was only talking about runtime. If you really > want to avoid GTK on a server then you should stick to one of the -bin > packages. Hopefully Java 9 will improve on this. > Apologies: I was actually thinking of icedtea-bin... which ALSO pulls in GTK due to IUSE defaults.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/02/2017 11:08 AM, Rich Freeman wrote: > > Which is simpler, a minimal profile that sets USE=-* and then lists a > few exceptions where that breaks in package.use, or an upstream > defaults profile (which becomes the basis for all the other profiles) > that has a 5000 line package.use file that specifies the upstream > defaults for every package in the repository? > It's honestly hard to say. I see your point, but "a few exceptions" might not be so few. Every IUSE default that (1) enables something critical, or (2) enables a default choice for a REQUIRED_USE constraint would need to be added back to the minimal profile. And of course the reason I started this thread is that those two usages are common. I clearly had the "minimal base" profile in mind, but the fact that (1) and (2) are used throughout the tree creates problems for any minimal profile, even is the base profile is "upstream defaults." If (base == minimal), then all of the upstream defaults need to be added to package.use for the upstream-defaults profile. That's bad, but if (base == upstream-defaults), then the important IUSE defaults need to be copy/pasted from our ebuilds into the minimal profile. The latter is more spiritually damning =)
Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults
On 02/02/2017 11:18 AM, William L. Thomson Jr. wrote: > > If you look at dev-java/icedtea ebuild you will see > > # Gtk+ will move to COMMON_DEP in time; PR1982 > > I cannot find PR1982 referenced to link. But shows that it is needed and > causes > issues without being set. > I don't really want to fight about this. I have USE="-gtk" for icedtea-bin, and run a few happy websites through Tomcat that haven't yet noticed that GTK is missing. But more importantly, icedtea-bin was just one example that I had in mind. There are hundreds of others in the tree.
Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults
On 02/02/2017 12:06 PM, William L. Thomson Jr. wrote: > >> But more importantly, icedtea-bin was just one example that I had in >> mind. There are hundreds of others in the tree. > > Sure, but some packages themselves go against a minimalist approach due to > their own build requirements. You have to fight the package to make them > minimal and I am not sure the fight is worth it at times. > We agree on that. If making GTK optional for your package is too much trouble, then don't make it optional. The problem is only when the maintainer does make it optional, and then defaults it on in every profile using IUSE defaults. Most "give the user a typical system" USE defaults belong in a desktop or server profile, not in the base.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/02/2017 12:23 PM, Walter Dnes wrote: > On Thu, Feb 02, 2017 at 09:11:26AM -0500, Michael Orlitzky wrote > >> 2 To avoid an unsatisfied REQUIRED_USE by default. >> >> * Example: having a non-empty RUBY_TARGETS by default. > > What's wrong with having emerge spit out an error message, and telling > the user that they need to set a flag to one of 2-or-more options? > If everything is already sorted out on your machine, and the package you're trying to install is something you care about, then you're right: I think most people would like to be prompted and make a choice. But imagine a fresh install, where you've set your USE flags and are about to do the final emerge -e @world. It's going to stop and prompt you 1,000 times to e.g. pick a ruby implementation, when I don't want ruby and don't care about ruby but it just happens to be used in the build system for webkit-gtk. If 90% of the prompts are for things like that, people will start defenestrating their Gentoo systems.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/02/2017 06:41 PM, Ian Stakenvicius wrote: > Responding here instead of the first time it was posted, just 'cause. > > On 02/02/17 06:35 PM, james wrote: >> " >> I'm not saying that we should have a minimal experience out-of-the-box, >> only that the base profile should result in an effectively-minimal set >> of USE flags. Adding IUSE defaults is essentially adding defaults to the >> base profile." > > Yes. More specifically, it's adding these defaults without setting > the flags globally, thereby not introducing system-wide defaults > across all packages but only those that make sense on a per-package > basis for that package to operate properly. > > IMO this is the effectively minimal-set of use flags we should have. I... agree? We should enable the flags that are necessary for the package to work, and we should enable whatever is necessary to avoid REQUIRED_USE roadblocks. That's what I started out by suggesting.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/02/2017 01:01 PM, Rich Freeman wrote: > On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky wrote: >> >> If (base == minimal), then all of the upstream defaults need to be added >> to package.use for the upstream-defaults profile. That's bad, > > I'll go further and say that it is unacceptably bad. > Only if anyone wants an upstream-defaults profile. But nobody's asked for one, in contrast with the large number of users who want minimal. > Is there a better way we can have our cake and eat it too? I'll admit > that a huge package.use on the minimal profile isn't a whole lot > better than a huge package.use on all the other profiles. Every important upstream default is already enabled in some profile. If dropping a particular IUSE default breaks desktop systems, then that flag belongs enabled in the desktop profile. If it breaks every system, then let's keep it default. > Do we need another form of syntax in individual ebuilds to try to > separate out the various cases you cite? Does anybody care to > actually suggest one? Definitely not. I was hoping to simplify things, not complicate them. We have a list of flags that can be enabled for each package. As a general principle, it makes sense to either (a) disable them all by default, or (b) enable them all by default. Having what is essentially a random selection enabled by default for each package is chaos. > I still think that we shouldn't encourage users to lightly deviate > from all the upstream defaults. Deviating from upstream defaults is why we have USE flags in the first place. No one really wants the upstream defaults, they want (nothing) + (what their profile provides) + (what they enable), not least of all because that assumption is how they came up with the list of flags in (what they enable) in the first place. If dropping an IUSE default hurts some profile, then stick the default in that profile. Nothing breaks, and it's not too much work, and we get back to a sane system of profile inheritance rather than having every ebuild and profile trying to XOR one another.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/02/2017 09:00 PM, Sam Jorna wrote: > > Consider: a new user, coming from Ubuntu or Fedora or Windows, starts > building their system. They start installing packages they want, only to > find that half of the package isn't there because no USE flags were > enabled. They have to enable these flags for almost every package they > want because there's no defaults, you must manually specify anything > that's not a direct dependency or forced by profile. Desktop profile!! We have a desktop profile!!! Why is the base profile a better location for new-user-with-a-desktop defaults than the **desktop** profile? I'm going crazy. I give up.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/02/2017 09:22 PM, Sam Jorna wrote: > > Also, how would this work with local USE flags as opposed to global > flags? Would they be acceptable to have IUSE defaults? > Exactly the same way as global flags: drop an entry in the desktop profile's package.use.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/02/2017 09:31 PM, Rich Freeman wrote: > > The desktop profile is going to do things like enable X11 support by > default. It isn't going to do things like enable bzip support in > ffmpeg (but not the new experimental codec that causes it to crash 25% > of the time, but which apparently works great if you use libav > instead), or tools support in tripwire, or e2fsprogs support in > libarchive, or threads support in beecrypt, or any of a million other > things that aren't desktop-specific. Then throw in an intermediate profile base -> all-that-junk -> desktop and everyone that's inheriting from base now can inherit from the new profile instead. Nothing changes, except we get the cruft out of base and into a new profile that people can ignore. The defaults are still recorded once, in one place. Just in a profile now instead of in IUSE.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/02/2017 10:16 PM, Patrick McLean wrote: > > There are people who run servers on Gentoo, and don't particularly want > minimalism, then want a normal Linux system level of functionality (ie > upstream and/or sane defaults) without having to add dozens of USE > flags to random packages throughout the system. > Then somebody should go through a typical Ubuntu install and add all of those packages to @system. That will make most people happy, and the minimalists can just mask what they don't need.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/03/2017 08:21 AM, Ian Stakenvicius wrote: >> >> How about rather changing our defaults to satisfy the minimalists who >> don't mind drastically reduced functionality and usability in pursuit >> of "minimalism" we just strive to make USE="-*" mostly usable, so the >> minimalists can get what they want, while still having sane defaults. >> > > I'm in favour of this too -- I know we don't "officially" support > USE="-*" but I think we should still strive to make it work with > minimal effort to end-users -- that effort being mainly setting > whatever is necessary for REQUIRED_USE resolution. > It will never be easy, because USE="-*" overrides your profile. What people want is a way to have USE="-*" apply between the base profile and the one that they select. This is all easily fixed by creating a new profile one-level above base where developers can put their favorite USE flags: 1. We create a new empty profile called "penultimate" inheriting from base. 2. Update the profiles that inherit from base to inherit from penultimate. 3. Move every upstream and maintainer-pet IUSE default into the penultimate profile. 4. Make it policy that IUSE defaults should only be used for critical flags and REQUIRED_USE persuasion. 5. Now we can create embedded, hardened, etc. profiles that inherit from base and get a minimal working set of USE flags.
Re: [gentoo-dev] Re: Requirements for UID/GID management
On 02/03/2017 09:51 AM, Martin Vaeth wrote: > Michael Orlitzky wrote: >> >> The fact that all permission and ownership information is shared is >> precisely the problem. When you change ownership of the hardlink (which >> you'll never know is a hardlink), you change ownership of /etc/shadow. > > Why should this be a problem except for a race between reading > and changing the ownership? > Admittedly, by using "find ... -exec ... +" the time for an exploit > of the race is even increased when a "standard" chown command is used. > > However, it is no rocket science to write a race-free chown command > in C: Just open the file and use stat() and fchown() to be sure to > change only files from the "correct" user. > > Since this works on the filehandle and not on the filename, I think > that there is no possibility for an exploit when this is used in the > above find loop. Not a bad idea... we chould ship that safe-chown utility, and then tell users how to use it to fix their UIDs. The draft that I wrote up was for the "fixed UID with random fallback" model, but said utility could still be useful for people who want to change their running systems to use the same UIDs that would have been chosen by default.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/03/2017 10:30 AM, Ian Stakenvicius wrote: > > ok you lost me. Could you provide an explicit example of what you > would want to see enabled in the profile (while everything else is > disabled) that you don't get when USE="-*" is set? USE="hardened pax_kernel ..." > > It's sounding more and more like you just want to be able to turn off > all IUSE defaults, and you can effectively do that by changing the USE > order can't you? I don't want to turn off all IUSE defaults. Since we have no policy on what IUSE defaults should be used for, half of them are important, and the other half are junk. I don't want to disable the ones that are critical for the package to function, and I don't want to disable the ones that satisfy an (otherwise unsatisfied) REQUIRED_USE constraint.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/03/2017 01:33 PM, Patrick McLean wrote: > > We might as well go back to before IUSE defaults then. Part of the > advantage of IUSE defaults is maintainers don't all have to fiddle with > the profiles, everything can be self-contained in the ebuild. This > drastically complicates maintenance, having two locations to track and > change rather than just one. You still retain the benefit for IUSE defaults that actually belong in the base profile, just not for upstream defaults or the ones that you personally prefer. > I suspect that there is a small subset > of people interested in this, and perhaps those people could maintain a > "minimal" profile that unsets IUSE defaults. Then every IUSE default gets recorded twice: once when the maintainer puts it in the ebuild, and once when I add it (negated) to the minimal profile. That's a bad design even if we pretend that I can solve the problem of tracking every IUSE change in the tree. > Also, I would just point out that the particular IUSE default that > you objected to in your original email does not really affect this > "minimalist" ideal that you seem to hold. The "hpn" USE flag on > openssh does not actually pull in any extra dependencies, it just > adds some optimizations to the network code to make it faster. > Yeah, that. OpenSSH is probably the most security-critical package on our systems. OpenSSH is maintained upstream by a talented team of security-conscious people. The HPN patch is, a) a third-party patch... b) that has been rejected by the talented security-conscious team... c) and is useless for most people. So why are we deciding for our users that they must have it?
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/03/2017 08:07 PM, Patrick McLean wrote:
>
> I think the current policy of "maintainer's discretion" is probably the
> only reasonable way to approach IUSE defaults...
>
> Leaving the IUSE defaults up to the maintainer allows said maintainer
> to select what they consider reasonable defaults.
>
This is the way we currently do things:
DEFAULTS="+apples -pears +potatoes -chicken +steak +broccoli +spatula"
FRUIT="${DEFAULTS} +pears -potatoes -steak -broccoli -spatula"
MEAT="${DEFAULTS} -apples -potatoes +chicken -broccoli -spatula"
VEGETABLES="${DEFAULTS} -apples -steak -spatula"
MISC="${DEFAULTS}"
Compare with:
DEFAULTS=""
FRUIT="+apples +pears"
MEAT="+chicken +steak"
VEGETABLES="+potatoes +broccoli"
MISC="+apples -pears +potatoes -chicken +steak +broccoli +spatula"
One of those is stupid, regardless of what you like to eat.
Re: [gentoo-dev] Re: Requirements for UID/GID management
On 02/04/2017 03:50 AM, Christopher Head wrote: >> >> Not a bad idea... we chould ship that safe-chown utility, and then >> tell users how to use it to fix their UIDs. The draft that I wrote up >> was for the "fixed UID with random fallback" model, but said utility >> could still be useful for people who want to change their running >> systems to use the same UIDs that would have been chosen by default. > > Are you sure that said utility isn’t simply “chown --from”? > One would hope that if they implemented it, that they did it safely -- but alas it's not standard.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/07/2017 02:52 AM, Ulrich Mueller wrote: > > I see no point in discouraging IUSE defaults, given that they are > purely advisory for the package manager: > > "[...] any use flag name in IUSE may be prefixed by at most one of a > plus or a minus sign. If such a prefix is present, the package manager > may use it as a suggestion as to the default value of the use flag if > no other configuration overrides it." [1] > > Portage can be made to ignore IUSE defaults by omitting "pkginternal" > from USE_ORDER, i.e. by adding the following line to make.conf [2]: > > #USE_ORDER="env:pkg:conf:defaults:pkginternal:repo:env.d" > USE_ORDER="env:pkg:conf:defaults:repo:env.d" > > One could even think about adding this to a future minimal profile. > The thread wasn't about discouraging IUSE defaults, rather to decide when they are appropriate. You cannot omit "pkginternal" from USE_ORDER, because you will break all of the packages whose defaults are either critical to the package, or prevent a REQUIRED_USE conflict. If that means IUSE defaults are the wrong solution to those problems, then it would be beneficial to have some "Guidelines for IUSE defaults" so that developers solve the problems correctly.
Re: [gentoo-dev] Guidelines for IUSE defaults
On 02/09/2017 03:41 PM, Daniel Campbell wrote: > That's a great question. Based on a cursory look at make.conf's manpage, > USE_ORDER without 'pkginternal' will ignore IUSE defaults as intended. > This has already been suggested like five times =P So long as people insist on using IUSE defaults for flags that are critical to the package and to satisfy REQUIRED_USE (sprinkled liberally throughout the tree), this won't work. You'll turn off the defaults that are critical, too, and throw a wrench into dependency resolution.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 04:58 AM, Alexis Ballier wrote:
>
> Is it really abusing ?
> := deps in DEPEND only would also make sense for e.g. code generators
>
Slot operator dependencies are ignored in DEPEND:
Indicates that any slot value is acceptable. In addition, for runtime
dependencies, indicates that the package will break unless a matching
package with slot and sub-slot equal to the slot and sub-slot of the
best installed version at the time the package was built is available.
In other words, the ":=" only does something special in RDEPEND. That
makes sense when you think of it as meaning "the thing will break"
rather than "I want to do a rebuild." The only reason it's not an error
to put them in DEPEND is because it would annoy everyone doing
DEPEND="${RDEPEND}".
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 09:24 AM, Mike Gilbert wrote:
>>
>> In other words, the ":=" only does something special in RDEPEND. That
>> makes sense when you think of it as meaning "the thing will break"
>> rather than "I want to do a rebuild." The only reason it's not an error
>> to put them in DEPEND is because it would annoy everyone doing
>> DEPEND="${RDEPEND}".
>
> Portage has interesting behavior for ":=" in DEPEND: it varies
> depending on your "with-bdeps" setting.
>
This is why we can't have nice things.
From recruiting-simplifies+bncbczi37v74ejrbhpb4dcqkgqevmgh...@googlegroups.com
Thu Mar 02 06:48:21 2017
Return-path:
Envelope-to: arch...@mail-archive.com
Delivery-date: Thu, 02 Mar 2017 06:48:21 -0800
Received: from c7-b.mxthunder.net ([208.53.48.218])
by mail-archive.com with esmtp (Exim 4.76)
(envelope-from
)
id 1cjS1l-0004Mw-J8
for arch...@mail-archive.com; Thu, 02 Mar 2017 06:48:21 -0800
Received: by bolt10b.mxthunder.net (Postfix, from userid 12345)
id 3vYwCz12fsz1x6S9; Thu, 2 Mar 2017 06:48:03 -0800 (PST)
Received: from mail-ot0-f185.google.com (mail-ot0-f185.google.com
[74.125.82.185])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by bolt10b.mxthunder.net (Postfix) with ESMTPS id 3vYwCf50k0z1w6cq
for ; Thu, 2 Mar 2017 06:47:58 -0800 (PST)
Received: by mail-ot0-f185.google.com with SMTP id i1sf42597331ota.0
for ; Thu, 02 Mar 2017 06:47:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20161025;
h=sender:message-id:date:subject:from:reply-to:mime-version
:content-transfer-encoding:feedback-id:x-original-sender
:x-original-authentication-results:precedence:mailing-list:list-id
:x-spam-checked-in-group:list-post:list-help:list-archive
:list-unsubscribe;
bh=uzvc0Q02asumLIIfovb8DCn3aEcZPE52kTwHSzf5HgM=;
b=LrohXxoiE/IS0VIzh1kiidCKSdQH5/ltxfaHDjfnhj4OhpTGSKnDWLhijp0zYieErP
G8efzJZBbR3q+i4ynrbGGlGLdtrZlau3ePYfHFWt3B7i3xwvdgO5g6rPHfKxkieWJyyc
CptEmLEUxscTmpc2zMVBjZcXBTqGDh7aBYbzFjbtiKq4563dl5LIpNGMOdjmgvu1DagE
vgxCngrAdowlAwm+clMHsvnqzsMfWeS3UF3NCZ1y+F1CU8zvLZtel4utqT4caEcn7f73
x0WZPUSce/4GF+/TlPsLVhpNg29e45c90g8i3do9FcLOg0u9qKdOLV8m6sWY158yMWob
iipQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=sender:x-gm-message-state:message-id:date:subject:from:reply-to
:mime-version:content-transfer-encoding:feedback-id
:x-original-sender:x-original-authentication-results:precedence
:mailing-list:list-id:x-spam-checked-in-group:list-post:list-help
:list-archive:list-unsubscribe;
bh=uzvc0Q02asumLIIfovb8DCn3aEcZPE52kTwHSzf5HgM=;
b=CRGSKoKvisS5r6a3Tg9AdzSi8JuvUrH3YO/iQgxigotVNGwU1ka9OB6qQCBmrPFTZ6
+wRaFulb/NI8c+qDIqxq2YGHFeuHSEgqnAsH1F06UEXUwZZdZFdhqQHdy3qvRNbiVFsr
dD7IDZW3xVJVeUs65oFGUBXgPGht8a4rWtYzlLQ1vLbWJXKQ6DxsxmHVpML5vtPgsns2
t9L7zhIqvV+oBr/kZByZLjMbIkp+H/M01Hu/bDBiX0qwcQVFpStTx6+7cUSApUZXUsPF
mv+pLBhVVJ+iy0eBoT6ze3AoEdHFnFvbAUKBs296ZTEu5JWgF35sXyNHuENqcQKf4E9u
PfAQ==
Sender: recruiting-simplif...@googlegroups.com
X-Gm-Message-State:
AMke39mzTJPQ8HlkO4TvxDIFEaJE+EM/G5GdlrBEcI7wFP06h/n3Bp0NheTOHKJYnyaJqQ==
X-Received: by 10.36.25.140 with SMTP id b134mr749103itb.6.1488466078157;
Thu, 02 Mar 2017 06:47:58 -0800 (PST)
X-BeenThere: recruiting-simplif...@googlegroups.com
Received: by 10.107.134.99 with SMTP id i96ls2076467iod.1.gmail; Thu, 02 Mar
2017 06:47:57 -0800 (PST)
X-Received: by 10.107.47.2 with SMTP id j2mr2693169ioo.74.1488466077742;
Thu, 02 Mar 2017 06:47:57 -0800 (PST)
Received: from a10-127.smtp-out.amazonses.com (a10-127.smtp-out.amazonses.com.
[54.240.10.127])
by gmr-mx.google.com with ESMTPS id r6si907363ywb.6.2017.03.02.06.47.57
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Thu, 02 Mar 2017 06:47:57 -0800 (PST)
Received-SPF: pass (google.com: domain of
0100015a8f7de508-59f183c1-021f-4d2c-bcff-9b4935b43c6d-000...@amazonses.com
designates 54.240.10.127 as permitted sender) client-ip=54.240.10.127;
Message-ID:
<0100015a8f7de508-59f183c1-021f-4d2c-bcff-9b4935b43c6d-000...@email.amazonses.com>
Date: Thu, 2 Mar 2017 14:47:56 +
Subject: Recruiting-Simplifies Required: UX Designer with Java Script,
Wireframe experience at Ann Arbor, Michigan - Contract
From: Vamsheedhar
Reply-To: vams...@svktechinc.com
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-SES-Outgoing: 2017.03.02-54.240.10.127
Feedback-ID: 1.us-east-1.BO8466vaYeUUNkpWGH0T2SyjKobAnSC2l7VlzcJ44uA=:AmazonSES
X-Original-Sender: grou...@rekruiteasy.com
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@amazonses.com; spf=pass (google.com: domain of
01
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 02:05 PM, Zac Medico wrote: >> >> This is why we can't have nice things. > > For those that are interested, I'm planning to to make --with-bdeps > automatically enabled when possible: > I agree with this ^ but I don't think portage should rebuild for DEPEND at all. It creates one more dangerous "it works in portage!" situation that will plague users of other package managers. (I'm not saying it couldn't be useful, but it should go in the next EAPI if we're gonna do it.)
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 04:06 PM, Zac Medico wrote: >> >> I agree with this ^ but I don't think portage should rebuild for DEPEND >> at all. It creates one more dangerous "it works in portage!" situation >> that will plague users of other package managers. >> >> (I'm not saying it couldn't be useful, but it should go in the next EAPI >> if we're gonna do it.) > > PMS doesn't specify when rebuilds are supposed to be triggered. You can > consider the rebuilds as a means to satisfy the dependencies. Saying > that the package manager should not make an effort to satisfy > dependencies would be silly. It doesn't violate the PMS to do the extra rebuilds, but the PMS also doesn't say that they should happen. Hypothetical situation: a developer notices that Go packages need to be rebuilt when the compiler changes, so he adds subslot operators to DEPEND and everything looks fine. Until someone with a different package manager tries to use it, that is; the rebuilds aren't triggered unless you're using portage.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 04:30 PM, Ciaran McCreesh wrote: > > The point is to specify dependencies declaratively. A dependency > expresses a dependency, not an action. If you can't express the kind of > dependency you need, then we need either labels or another *DEPEND > variable to take care of it, not a bodge. > In the meantime, if you give people an official bodge-maker, they'll use it. Back on topic: What kind of dependency do we need, anyway? William, are you saying that if I upgrade dev-lang/go, then things will break, but if I delete dev-lang/go, everything is fine?
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/02/2017 04:53 PM, Alexis Ballier wrote: >> >> Back on topic: >> >> What kind of dependency do we need, anyway? William, are you saying >> that if I upgrade dev-lang/go, then things will break, but if I delete >> dev-lang/go, everything is fine? > > It's likely like ocaml: you link your programs ~ statically but > everything you link needs to be built with the same compiler. So > that'd be some kind of "build against"-RDEPEND. > The tiny practical part of me thinks it's probably better to add dev-lang/go:= to RDEPEND than it is to create an entirely new class of dependencies to handle this.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/07/2017 05:40 PM, William Hubbs wrote: > Hi all, > > I was attending SCALE, but now I'm back to answer this. > > On Thu, Mar 02, 2017 at 04:46:22PM -0500, Michael Orlitzky wrote: >> What kind of dependency do we need, anyway? William, are you saying that >> if I upgrade dev-lang/go, then things will break, but if I delete >> dev-lang/go, everything is fine? > > Go programs will not *break* if you upgrade or downgrade dev-lang/go, but > they will not get the new features or fixes in the new version of > dev-lang/go until they are rebuilt with the new version. Ha, then I went off on a pointless tangent. How is this situation different from, say, a C program? You need to recompile to get the new GCC optimizations, stack-mumbo-jumbo protections, etc.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/07/2017 07:02 PM, Patrick McLean wrote: > > You also need to recompile to get security bugs fixed. With go it's not > just compiler options, it's also the standard library updates that need > a recompile to get. > If that's the reasoning, then don't you have the same problem with every other library under dev-go? None of them are really needed at runtime, but you would need to rebuild when they change to get security updates, right? If all dev-go libraries wind up in RDEPEND solely to force rebuilds on upgrades, why not do the same with the standard library (dev-lang/go)?
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/08/2017 01:27 AM, Zac Medico wrote: > On Tue, Mar 7, 2017 at 4:38 PM, William Hubbs wrote: >> On Tue, Mar 07, 2017 at 07:13:38PM -0500, Michael Orlitzky wrote: >>> If all dev-go libraries wind up in RDEPEND solely to force rebuilds on >>> upgrades, why not do the same with the standard library (dev-lang/go)? >> >> They should not end up in rdepend at all since we only need them at >> build-time. > > Shouldn't we get rebuilds when the dev-go libraries are upgraded too? > That's what I was getting at. Another reading of the PMS reminds me (as Kent pointed out) that slot-operator deps shouldn't be used for would-be-nice stuff. It says specifically that := "indicates that the package will break..."
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/08/2017 02:20 PM, William Hubbs wrote: > > Another option is to not force this and rely on everyone to use > --with-bdeps=y to make the rebuild happen. > That feature is portage-only. Slot operator deps in DEPEND are meaningless.
Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies
On 03/09/2017 10:36 AM, William Hubbs wrote: > On Wed, Mar 08, 2017 at 07:49:08PM -0500, Michael Orlitzky wrote: >> On 03/08/2017 02:20 PM, William Hubbs wrote: >>> >>> Another option is to not force this and rely on everyone to use >>> --with-bdeps=y to make the rebuild happen. >>> >> >> That feature is portage-only. Slot operator deps in DEPEND are meaningless. > > Having things in RDEPEND that are only used at build time is also incorrect. I was not implying that you have to pick one of the two wrong solutions and implement it =) The attractive options at this point are, 1. Do nothing. 2. Work with the PMS team to come up with a solution for the problem. The other proposed solutions don't work: * Using RDEPEND is semantically incorrect, and runs afoul of the PMS because the packages don't break when their dependencies change. * Using slot operator deps in DEPEND is meaningless, and only happens to do what you want in portage when --with-bdeps is enabled. Going forward with either one of those only digs us deeper into the hole we're already in. "How do we update insecure libraries?" would have been a good question to ask *before* adding Go to the tree, because the answer is pretty clearly "we can't." The right way to fix it now is to create a new class of dependencies for the CADT languages that ignore the last 40 years of experience and statically link everything.
Re: [gentoo-dev] [patch] golang-vcs-snapshot.eclass: add vendoring of external dependencies
On 03/09/2017 01:21 PM, William L. Thomson Jr. wrote:
> Pretty sure no need for the ||die, rm -fr should never fail.
>
> rm -fr "${VENDOR_PATH}/${VENDORPN}" || die
>
$ rm -rf /bin/cp || echo "it failed"
rm: cannot remove '/bin/cp': Permission denied
it failed
Re: [gentoo-dev] [patch] golang-vcs-snapshot.eclass: add vendoring of external dependencies
On 03/09/2017 02:00 PM, William L. Thomson Jr. wrote:
>
> Under what circumstances?
>
> ...
>
> Seems like it is not possible to generate the above permission issue.
>
I can make them up all day...
* VENDOR_PATH=VENDORPN="" and we try to "rm -rf /"
* A hard drive error occurs.
* Bad memory crashes "rm".
* Somebody is running a recursive chmod on /var/tmp during emerge.
* The tarball contains something you don't expect and can't delete.
...
Ultimately, the die() is there to catch precisely all the things that
should never ("will never") happen.
Re: [gentoo-dev] [patch] golang-vcs-snapshot.eclass: add vendoring of external dependencies
On 03/09/2017 06:16 PM, William L. Thomson Jr. wrote:
>
> Case in point dev-db/firebird use to have a line like
>
> rm -rf "${S}"/extern/{btyacc,editline,icu} || die
>
> But if you look at current ebuild it is now
>
> rm -r "${S}"/extern/{btyacc,editline,icu} || die
>
> The force option/argument was dropped. Why? Seems it could have remained.
> Which is why I commented, as I am pretty sure that has been said to me before.
Whether "-f" is appropriate or not depends on the context.
With firebird, you expect all of those directories to exist, and you
want to be notified (so that you can update the ebuild) if one of them
isn't there. If upstream unbundles those three libraries and you're
doing "rm -rf", then you'll never notice, and that (now pointless) line
of code will stay there forever.
In the golang-vcs eclass, you truly don't know that the directory will
exist, so "-f" is needed to avoid a "no such directory" error.
> Essentially do not use -f with || die or something to that effect. Maybe for
> different reasoning. Still one of those things I never liked. Do it this way,
> for this reason, that is not documented. Others may digress and leads to
> confusion.
There's an easy rule: always use "|| die" on commands that don't die
themselves. It's always better to fail as soon as something unexpected
happens. Otherwise it's probably going to fail later anyway, and you'll
waste a whole lot of time trying to figure out why it *really* failed.
There are exceptions to the rule, but it should be really obvious when
you hit one, like if you have a test suite that always returns 1.
Re: [gentoo-dev] [PATCH] epatch.eclass: Split epatch* logic from eutils
On 03/11/2017 08:51 AM, Michał Górny wrote: > > However, the inherit will be removed in EAPI 7 > > ... > > -inherit estack multilib toolchain-funcs > +inherit epatch estack multilib toolchain-funcs > Would it hurt to do that now, so that we don't forget when EAPI 7 comes? For EAPI=0 to 6, inherit them all; otherwise, inherit the old set of eclasses (without estack or epatch).
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On 03/23/2017 09:36 AM, Alexis Ballier wrote:
No, the argument is about "we want to clean up the tree from abusive
hacks".
This is yours. Mike's answer is merely asking for proper justification
and doesn't seem to have had an answer yet.
The PMS[0] says
Ebuilds must not access [FILESDIR] in global scope.
But, for example, autoconf-2.69-r2.ebuild does,
if [[ -z ${__EBLITS__} && -n ${FILESDIR} ]] ; then
source "${FILESDIR}"/eblits/main.eblit || die
fi
in global scope.
I think there are some related patches to block this sort of thing in
portage, but portage can't be improved while a critical package is doing
the thing that we want to prevent.
[0] https://dev.gentoo.org/~ulm/pms/head/pms.html#fn4x12
Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
On 03/23/2017 04:22 PM, Alexis Ballier wrote: Indeed, according to pms.git commit log, the rule was laxed because it was clearly an oversight in EAPI6 [1] and was the standard behavior in previous EAPIs. But in the same commit, an "harmless note" was added that "Ebuilds must not access the directory in global scope." in addition to the "May or may not exist" statement and "Not necessarily present when installing from a binary package" footnote. Please explain how this last addition is not a backwards-breaking change. PMS is not a tool to push your personal agenda of cleaning up the deve^^err tree. [1] https://gitweb.gentoo.org/proj/pms.git/commit/?id=fa4ac9474048ec75af138fc61f22485c06aac5b7 Read that diff again. Before the commit, FILESDIR was invalid in global scope (only valid in src_*). This commit makes it valid in global scope, but adds the "... don't access it there" clause. It's not a breaking change because any behavior affected by the clause was already illegal before the commit.
Re: [gentoo-dev] Review: xemacs-packages-r1.eclass
On 04/02/2017 05:05 AM, David Seifert wrote:
[[ ${XEMACS_PKG_CAT} ]] || die "XEMACS_PKG_CAT was not defined before inheriting
xemacs-packages-r1.eclass"
case ${XEMACS_PKG_CAT} in
standard|mule|contrib)
;;
*)
die "Unsupported package category in XEMACS_PKG_CAT"
;;
esac
I think that the first check is redundant, but it isn't important if you
don't feel like changing it.
Elsewhere: quoting the variables when they're used would produce better
error messages if somebody puts something stupid in the variables.
Re: [gentoo-dev] Reverse use of Python/Ruby versions
On 04/09/2017 12:15 PM, William L. Thomson Jr. wrote: Not sure if this is practical, it may be less work if the use of Python and Ruby versions ( maybe others ) is reversed. Rather than adding all the versions that the ebuild supports. What if it only included versions it did not support? Even if this would work better, it would require retraining all developers, completely rewriting several eclasses, tons of documentation, and a few thousand ebuilds. No one's going to jump on that bandwagon without a proof-of-concept that works much better than what we have now.
Re: [gentoo-dev] Reverse use of Python/Ruby versions
On 04/09/2017 07:15 PM, William L. Thomson Jr. wrote: If the package failed, all that would need to be done kinda like now is a given variable modified in the ebuild. Just marking what ever it did not work with. As mentioned that could be done via my ebuild-batcher[1], though same functionality is easily replicated. How do you plan to test a thousand packages against the new version of python, and then revision/stabilize all of the broken ones immediately? Or is the plan to just break everyone's systems, and ask them to report bugs for the things that stopped working? I think what you will actually get as a result is that nobody will ever add a new version of python to the tree, because you've just made it a huge ordeal to do so.
