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 wit
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 th
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:
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/eap
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?
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) h
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
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 i
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 b
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
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 peo
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 c
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@$
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
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 script
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
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
>&g
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 solu
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
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
bei
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*
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,
>>> et
On 03/16/12 11:18, Greg KH wrote:
>
> At least find a package that people use :)
>
www-client/httrack?
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/
Ty
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 c
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".
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
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
>> an
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 re
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 --
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 failu
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 includ
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 not
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-visibi
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?
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 shou
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
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
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
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
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 th
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 v
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 pr
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 prob
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 a
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
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
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)
-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 work
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
>
>
-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
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.
>
>
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 se
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 manag
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.
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 (unneces
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 t
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 metadat
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
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.
>
>
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.
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 w
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 th
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
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 ha
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 havi
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 effective
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&
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
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.
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 work
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 through
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 t
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
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 a
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,
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
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 peop
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
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
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
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 becaus
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
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
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 bo
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 progr
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
>>
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
oth
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
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.
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 mak
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
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.
* Ba
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/argume
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, in
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]
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 direc
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 XE
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
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
1 - 100 of 919 matches
Mail list logo
