Re: [gentoo-dev] rfc: empty directories in ${D}

2018-04-01 Thread Ciaran McCreesh
On Sat, 31 Mar 2018 20:46:56 +0100
Andrey Utkin <andrey_ut...@gentoo.org> wrote:
> Right, I am not aware why PMS has left this explicitly undefined.

Because when we wrote the spec, Portage's actual behaviour on empty
directories was extremely tricky to define and depended upon things
like whether you were upgrading or reinstalling a package.

-- 
Ciaran McCreesh



Re: [gentoo-dev] News Item: Portage Dynamic Deps

2018-01-22 Thread Ciaran McCreesh
On Mon, 22 Jan 2018 11:28:21 +0100
"Andreas K. Huettel" <dilfri...@gentoo.org> wrote:
> Am Montag, 22. Januar 2018, 08:01:08 CET schrieb Zac Medico:
> > According to Gentoo policy, future ebuild dependency changes need
> > to be accompanied by a revision bump in order to trigger rebuilds
> > for users. Therefore, you should only need to use --changed-deps=y
> > for a single deep @world update. After that, if you encounter
> > installed packages with outdated dependencies in a future deep
> > @world update, then you should report it as a bug.  
> 
> Did you come up with a solution how to handle eclass-generated
> dependency changes then?
> 
> I'd loathe to have to do identical revision bumps for, say, all perl-
> module.eclass consumers...

perl-cleaner is rather strong evidence that the Perl situation needs a
major change anyway...

-- 
Ciaran McCreesh



Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-10 Thread Ciaran McCreesh
On Wed, 10 Jan 2018 17:48:32 -0500
"Aaron W. Swenson" <titanof...@gentoo.org> wrote:
> Modified a bit. This should show for anyone who has GnuCash installed.

For anyone who has any version of GnuCash installed, either now or at
any point in the future. (See the recent thread on expiring news
items...) Are you sure you don't just want to target this at people who
have the old version installed, instead?

-- 
Ciaran McCreesh



Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

2018-01-10 Thread Ciaran McCreesh
On Wed, 10 Jan 2018 19:35:52 +0100
Kristian Fiskerstrand <k...@gentoo.org> wrote:
> On 01/10/2018 07:31 PM, Aaron W. Swenson wrote:
> > Display-If-Installed: >=app-office/gnucash-2.7.0  
> 
> And we might want to display it before users actually upgrades if it
> is for backing up an auto migrated change?

Yes, this header is backwards. It's a message to be displayed to users
who have the old version, not a message to be displayed to users who
install the new version for the first time ever and who have never used
the old version.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: Deleting old news items

2018-01-06 Thread Ciaran McCreesh
On Sat, 6 Jan 2018 08:18:19 -0500
kuzetsa <kuze...@gmail.com> wrote:
> On 01/06/2018 05:05 AM, Ulrich Mueller wrote:
> >>>>>> On Sat, 6 Jan 2018, Duncan  wrote:  
> >> $ equery b news.eselect
> >> app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect)
> >> So in that case it's not the PM, but eselect.  
> > In fact, it is the PM that would do the filtering, before filling
> > the list of unread news items
> > in /var/lib/gentoo/news/news-gentoo.read.
> >
> > Filtering in eselect news would be problematic: Obtaining the list
> > of items with "eselect news list" and e.g. reading them with
> > "eselect news read" are issued as separate commands, which requires
> > that the list of valid items does not change. However, time-based
> > filtering could cause a race condition, like an item expiring
> > between execution of the two commands.
> 
> The race condition could be addressed by issuing a warning
> at or around the time when expirations occur (midnight),
> with or without detecting specific expirations which may
> have occurred:

How accurate is "around"? Obviously we'd need to introduce a user
configuration option so different users could set appropriate values
for their needs.

Seriously though, all this complexity is just highlighting that dates
are a really bad way of deciding when a news item should expire, and
that if we need anything, it's more Display-If conditions.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Deleting old news items

2018-01-03 Thread Ciaran McCreesh
On Wed, 3 Jan 2018 12:23:33 +0100
Kristian Fiskerstrand <k...@gentoo.org> wrote:
> Do we necessarily need to do even that? A package manager could have a
> feature to mask based on other heuristics without changing the format,
> e.g all messages from before X, presumably with a switch to show

Package manglers having to use heuristics when explicit information
could easily be provided by developers but isn't is the source of at
least 27.4% of Gentoo's problems.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

2017-09-08 Thread Ciaran McCreesh
On Fri, 8 Sep 2017 11:10:54 -0500
Gordon Pettey <petteyg...@gmail.com> wrote:
> And this is all irrelevant since the copyright applies to the
> software, not the location you obtain it from. Nobody commits
> copyright infringement by buying a used book from their neighbour
> instead of buying it at Half Price Books.
> Distribution licenses are another thing, but if the original SRC_URI
> from the ebuild wasn't RESTICT="fetch", what makes anybody think that
> would suddenly change with a new SRC_URI?

Are you a lawyer, and does this constitute legal advice? I ask, because
the lawyers I've spoken to about a similar issue seemed to think it
wasn't that simple.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

2017-09-08 Thread Ciaran McCreesh
On Sat, 9 Sep 2017 03:56:38 +1200
Kent Fredric <ken...@gentoo.org> wrote:
> > >> Sir, please see my above comment about building ballistic
> > >> missiles. It may be important for the Gentoo Foundation to add a
> > >> disclaimer similar to the one I mentioned. I would hate for the
> > >> Foundation or any of its administrators or contributors to be
> > >> found guilty of aiding and abetting terrorists.
> > >
> > > Yeah. Stop trolling, please.
> > >
> > 
> > I am being completely serious. You can find such a clause in the
> > iTunes license.
> > 
> > If it seems ridiculous please reconsider the subject in question.  
> 
> I'm not sure how enforceable that clause is as a License.

Until recently, there was a clause in the Nauty licence prohibiting use
in "military applications". This was sufficient for the highly paid
lawyers who looked at it to recommend not redistributing Nauty as part
of the GAP computer algebra system, because computer algebra could
conceivably be used for blowing stuff up.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: [PATCH] eapi7-ver.eclass: 'Early adopter' version of EAPI 7 version manip

2017-09-08 Thread Ciaran McCreesh
On Fri, 08 Sep 2017 14:54:10 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> W dniu pią, 08.09.2017 o godzinie 12∶48 +, użytkownik Martin Vaeth
> napisał:
> > Michał Górny <mgo...@gentoo.org> wrote:  
> > > +#   1.2b-alpha4 -> 1 . 2 '' b - alpha '' 4  
> > 
> > Is this only to explain the syntax or are there plans to
> > extend the allowed versions for pms?
> 
> It only explains how the functions parse stuff (except for ver_test
> which uses PMS rules). They are by definition supposed to work with
> random upstream versions.

This sounds like the sort of thing that could go horribly wrong... I
didn't design versionator to work with arbitrary messy stuff since the
main use is in manipulating Gentoo PV versions. Where are these other
versions coming from?

-- 
Ciaran McCreesh



Re: [gentoo-dev] [PATCH v3] eclass/kernel-2.eclass: Remove use of tr in global scope

2017-09-07 Thread Ciaran McCreesh
On Thu, 07 Sep 2017 07:42:31 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> >+if [[ "${EAPI}" -lt 6 ]]; then   
> 
> EAPI is not a number. The next one we'll call gray-grizzly just to
> prove the point.

Careful, you're turning into me.

-- 
Ciaran McCreesh



Re: [gentoo-dev] vim-syntax USE flag

2017-07-23 Thread Ciaran McCreesh
On Sat, 22 Jul 2017 16:27:39 -0400
Mike Gilbert <flop...@gentoo.org> wrote:
> Packages currently handle installation of vim syntax support files
> inconsistently. Some builds install the files if the "vim-syntax" USE
> flag is enabled, while others install them unconditionally.
> 
> Do these files fall into the "small text files" category for
> unconditional installation? If so, we should probably phase out the
> vim-syntax USE flag.
> 
> If we want to keep the USE flag, I would suggest documenting a global
> policy regarding its use. Should that live in the devmanual? Or maybe
> the Vim project page?

One potential issue is help files: any Vim plugin that comes with
documentation needs a little script (which requires Vim to be installed)
to be run in pkg_postinst.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

2017-07-10 Thread Ciaran McCreesh
On Mon, 10 Jul 2017 18:14:23 -0700
Raymond Jennings <shent...@gmail.com> wrote:
> If I may ask, does anyone have any profiling information one way or
> the other to shed light on the situation?

Paludis does complete dependency and unused package tracking for
everything by default. Any performance difficulties are
implementation-related, not a fundamental problem.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Sets vs Meta ebuilds

2017-07-10 Thread Ciaran McCreesh
On Mon, 10 Jul 2017 17:21:42 -0400
Ian Stakenvicius <a...@gentoo.org> wrote:
> On 10/07/17 04:47 PM, William L. Thomson Jr. wrote:
> > On Mon, 10 Jul 2017 15:36:11 -0500
> > Ben Kohler <bkoh...@gmail.com> wrote:  
> >>
> >> If you want dependencies checked, use the correct option which
> >> checks them.  This takes significantly longer than -C, as it's
> >> significantly more complex to check for.
> >>
> >> As far as I can tell, you are literally asking for -C to behave
> >> like -c, when you could just be using -c instead.  
> > 
> > No I simply want warnings like that exist for profiles and set
> > packages.
> > 
> > Also more information when attempting to remove a package that is
> > not removed.
> >   
> 
> OK, well, as Ben said it's not feasible to make -C act like -c due to
> the performance hit involved and due to the purpose of the command
> itself.

Have you profiled this? It shouldn't be slow if implemented correctly.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Sets vs Meta ebuilds

2017-07-10 Thread Ciaran McCreesh
On Tue, 11 Jul 2017 00:24:10 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> William, I'm not sure if you're aware of how package managers work but
> checking reverse dependencies of a package takes significant amount of
> time. Changing -C to do that would be a serious performance
> regression. Which would result in users requesting yet another option
> to disable this.

Eh, that's a Portage performance problem, not a package manager
performance problem.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: Sets vs Meta ebuilds

2017-07-08 Thread Ciaran McCreesh
On Sat, 8 Jul 2017 19:58:13 -0400
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
> On Sun, 9 Jul 2017 00:49:57 +0100
> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> > On Sat, 8 Jul 2017 19:39:33 -0400
> > "William L. Thomson Jr." <wlt...@o-sinc.com> wrote:  
> > > The two ways are not the same, and there is a reason sets exist in
> > > the first place. People seem to be over looking that fact. I did
> > > not add sets. They are not new.  I am simply trying to expand
> > > their use.
> > 
> > Sets exist because people keep saying "let's have sets!" without
> > agreeing on what sets actually are or how they are to be used.  
> 
> Do they need to agree? Isn't Gentoo about choice? Maybe your use of
> sets is different from mine. Is that not acceptable to have choice?

Well yes, they do need to agree, because otherwise when two different
developers put sets in a profile expecting different effects, then at
least two developers are going to end up confused, disappointed, and
quite probably breaking user systems.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: Sets vs Meta ebuilds

2017-07-08 Thread Ciaran McCreesh
On Sat, 8 Jul 2017 19:39:33 -0400
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
> The two ways are not the same, and there is a reason sets exist in the
> first place. People seem to be over looking that fact. I did not add
> sets. They are not new.  I am simply trying to expand their use.

Sets exist because people keep saying "let's have sets!" without
agreeing on what sets actually are or how they are to be used. Sets
remain half-baked because it turns out they don't make consistent sense
in different contexts when you give them a non-superficial amount of
thought.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints

2017-07-08 Thread Ciaran McCreesh
On Sat, 8 Jul 2017 16:39:29 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> > As much as I hate the weird || ( use ? ( ) ) and empty block rules,
> > it would be worse to have them apply in some situations but not
> > others.  
> 
> Indeed, makes sense. Would it also make sense to have some more
> logical meaning in a future EAPI ? I mean, in every context I've ever
> seen, applying a rule to the empty set is the neutral of that rule,
> so that it preserves associativity.
> That'd mean: || ( ) is false, && ( ) is true, ^^ ( ) is false, ?? ( )
> is false.

The sensible thing to do is ban it, and additionally ban use? ( )
inside || and ^^ (if we've not done that already...).

-- 
Ciaran McCreesh



Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints

2017-07-08 Thread Ciaran McCreesh
On Sat, 8 Jul 2017 16:14:09 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> On Sat, 8 Jul 2017 13:01:39 +0100
> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> > On Sat, 8 Jul 2017 13:49:56 +0200
> > Alexis Ballier <aball...@gentoo.org> wrote:  
> > > On Sat, 8 Jul 2017 12:26:59 +0200
> > > Ulrich Mueller <u...@gentoo.org> wrote:
> > > > | * An any-of group (||) evaluates to true if at least one of
> > > > the | items in it evaluates to true.
> > > > | * An exactly-one-of group (^^) evaluates to true if exactly
> > > > one of | the items in it evaluates to true, and all the
> > > > remaining items | evaluate to false.
> > > > | * An at-most-one-of group (??) evaluates to true if at most
> > > > one of | the items in it evaluates to true.
> > > > 
> > > > It should be added that any empty group (|| or ^^ or ??)
> > > > evalutates to true, because that's what PMS specifies:
> > > > https://projects.gentoo.org/pms/6/pms.html#x1-780008.2  
> > > 
> > > A bit OT, but that is *definitely* counter intuitive. What's the
> > > rationale and usecase behind this ?
> > 
> > Annoying special cases like || ( foo? ( ... ) bar? ( ... ) ) . The
> > original reason was that old versions of Portage would simply remove
> > unmet "flag? ( )" blocks internally. It was kept in EAPI 0 because
> > stuff in the tree used it back then.
> 
> Wasn't REQUIRED_USE something completely new with no prior usage in
> EAPI 3 ?

Yes, but the spec defines dependency-like structures and their meanings
once and consistently, rather than all over the place and
inconsistently.

As much as I hate the weird || ( use ? ( ) ) and empty block rules, it
would be worse to have them apply in some situations but not others.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints

2017-07-08 Thread Ciaran McCreesh
On Sat, 8 Jul 2017 13:49:56 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> On Sat, 8 Jul 2017 12:26:59 +0200
> Ulrich Mueller <u...@gentoo.org> wrote:
> > | * An any-of group (||) evaluates to true if at least one of the
> > | items in it evaluates to true.
> > | * An exactly-one-of group (^^) evaluates to true if exactly one of
> > | the items in it evaluates to true, and all the remaining items
> > | evaluate to false.
> > | * An at-most-one-of group (??) evaluates to true if at most one of
> > | the items in it evaluates to true.
> > 
> > It should be added that any empty group (|| or ^^ or ??) evalutates
> > to true, because that's what PMS specifies:
> > https://projects.gentoo.org/pms/6/pms.html#x1-780008.2  
> 
> A bit OT, but that is *definitely* counter intuitive. What's the
> rationale and usecase behind this ?

Annoying special cases like || ( foo? ( ... ) bar? ( ... ) ) . The
original reason was that old versions of Portage would simply remove
unmet "flag? ( )" blocks internally. It was kept in EAPI 0 because
stuff in the tree used it back then.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Sets vs Meta ebuilds

2017-07-07 Thread Ciaran McCreesh
On Fri, 7 Jul 2017 21:38:31 +0100
James Le Cuirot <ch...@gentoo.org> wrote:
> On Fri, 7 Jul 2017 12:48:04 -0400
> NP-Hardass <np-hard...@gentoo.org> wrote:
> > There is actually a huge functional difference between the two that
> > you are missing here.  A meta package defines its dependencies in
> > full dependency syntax.  This means you can specify versions, USE
> > flag dependencies, make packages dependent on USE flags, etc.  A
> > package set is just a list of packages (potentially constrained by
> > version.  TTBOMK, there is no inclusion of any USE flag
> > functionality in sets. Additionally, let's say you have a more
> > complicated dependency like || ( A B ),  I don't think there is a
> > way to describe that in a package set at all.  
> 
> Actually you can specify basic USE dependencies in sets. You can also
> specify SLOTs. For example, this is valid.
> 
> media-libs/tiff:3[abi_x86_32,jpeg,zlib,-cxx]

And this is one of many reasons "sets in profiles" isn't going to work:
we don't really know what most of this stuff means...

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-06-15 Thread Ciaran McCreesh
On Thu, 15 Jun 2017 19:30:02 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> On Thu, 15 Jun 2017 18:04:35 +0100
> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> > On Thu, 15 Jun 2017 18:55:45 +0200
> > Alexis Ballier <aball...@gentoo.org> wrote:  
> > > The guarantee comes from the fact that the output is always in the
> > > space of all possible inputs from the user. So, if some output
> > > will kill a kitten, so does some input.
> > 
> > USE=minimal
> > USE=mips
> > USE=-ssl
> >   
> 
> So what?

So, if the aim of this solution is to make things better for the user,
what are you doing to establish that this will make things better for
the user instead of recommending something awful?

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-06-15 Thread Ciaran McCreesh
On Thu, 15 Jun 2017 18:55:45 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> The guarantee comes from the fact that the output is always in the
> space of all possible inputs from the user. So, if some output will
> kill a kitten, so does some input.

USE=minimal
USE=mips
USE=-ssl

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-06-15 Thread Ciaran McCreesh
On Thu, 15 Jun 2017 18:37:16 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> > So you're saying that at the end of this, there's an ENFORCED_USE
> > solver that spits out some answer that may or may not be in any way
> > a sane solution to the conflict.
> > 
> > I don't see how that's helpful to a user.
> 
> Define sane.
> The definition of the solver is made to change the least possible of
> the inputs and is completely and easily predictable by the person
> writing the constraint. That is something I would call sane.

The problem is not just writing a resolver that spits out a valid
output. The problem is writing a resolver which will never go and
uninstall bash as a result of unintended combinations of inputs (which
Portage used to do, but there's now a special exception for system
packages, so it will only occasionally unexpectedly uninstall critical
packages that aren't explicitly in system due to virtuals instead).
This is *hard*.

A bad suggestion to the user is worse than no suggestion at all. Unless
you can safely determine that there aren't any unintended consequences
of your rule, the focus needs to be on producing good error messages
so the user can figure the problem out, not on producing bad solutions
that will confuse things even more.

-- 
Ciaran McCreesh 



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-06-15 Thread Ciaran McCreesh
On Thu, 15 Jun 2017 18:30:10 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> On Thu, 15 Jun 2017 17:22:26 +0100
> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> > On Thu, 15 Jun 2017 18:19:04 +0200
> > Alexis Ballier <aball...@gentoo.org> wrote:  
> > > On Thu, 15 Jun 2017 17:13:57 +0100
> > > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> > > > On Thu, 15 Jun 2017 18:07:00 +0200
> > > > Alexis Ballier <aball...@gentoo.org> wrote:  
> > > > > > The best way to convince me is through valid
> > > > > > examples.  
> > > > > 
> > > > > It is also easier to be convinced when you try to understand
> > > > > and ask for clarifications instead of just rejecting without
> > > > > thinking :)
> > > > 
> > > > The problem with this entire proposal is that it's still in
> > > > "well I can't think of how it could possibly go wrong"
> > > > territory. We need a formal proof that it's sound. History has
> > > > shown that if something can be abused by Gentoo developers, it
> > > > will be abused...  
> > > 
> > > Had you read the thread you would have noticed that I provided an
> > > algorithm giving sufficient conditions for the solver to work.
> > > That is, if developers pay attention to repoman warnings/errors,
> > > it will never fail. Obviously, since we're still in the SAT
> > > space, you can ignore the errors and make it fail, but it'll
> > > never be worse than what we currently have.
> > 
> > You have shown that you produce a solution, not the solution that's
> > actually wanted.
> 
> Since 'wanted' is still undefined, I'd say it produces the defined
> solution and you can adapt to the definition to get what you want.

So you're saying that at the end of this, there's an ENFORCED_USE
solver that spits out some answer that may or may not be in any way a
sane solution to the conflict.

I don't see how that's helpful to a user.

-- 
Ciaran mcCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-06-15 Thread Ciaran McCreesh
On Thu, 15 Jun 2017 18:19:04 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> On Thu, 15 Jun 2017 17:13:57 +0100
> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> > On Thu, 15 Jun 2017 18:07:00 +0200
> > Alexis Ballier <aball...@gentoo.org> wrote:  
> > > > The best way to convince me is through valid examples.  
> > > 
> > > It is also easier to be convinced when you try to understand and
> > > ask for clarifications instead of just rejecting without
> > > thinking :)
> > 
> > The problem with this entire proposal is that it's still in "well I
> > can't think of how it could possibly go wrong" territory. We need a
> > formal proof that it's sound. History has shown that if something
> > can be abused by Gentoo developers, it will be abused...  
> 
> Had you read the thread you would have noticed that I provided an
> algorithm giving sufficient conditions for the solver to work. That
> is, if developers pay attention to repoman warnings/errors, it will
> never fail. Obviously, since we're still in the SAT space, you can
> ignore the errors and make it fail, but it'll never be worse than what
> we currently have.

You have shown that you produce a solution, not the solution that's
actually wanted.

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-06-15 Thread Ciaran McCreesh
On Thu, 15 Jun 2017 18:07:00 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> > The best way to convince me is through valid examples.  
> 
> It is also easier to be convinced when you try to understand and ask
> for clarifications instead of just rejecting without thinking :)

The problem with this entire proposal is that it's still in "well I
can't think of how it could possibly go wrong" territory. We need a
formal proof that it's sound. History has shown that if something can
be abused by Gentoo developers, it will be abused...

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-06-05 Thread Ciaran McCreesh
On Mon, 05 Jun 2017 20:10:12 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> I'm sure Ciaran will love to elaborate ;-).

It's doomed. Even if you get it to work, which you won't, it won't
survive ten seconds contact with the enemy.

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

2017-06-02 Thread Ciaran McCreesh
On Fri, 2 Jun 2017 15:34:19 -0400
"Walter Dnes" <waltd...@waltdnes.org> wrote:
> On Fri, Jun 02, 2017 at 01:14:31PM +1200, Kent Fredric wrote
> > On Thu, 1 Jun 2017 09:38:01 -0400
> > "Walter Dnes" <waltd...@waltdnes.org> wrote:
> >   
> > >   As mentioned elsewhere, what happens when two or three other
> > > people do their own forks?  Plugin 1 works with vim A and B but
> > > not C or D.  Plugin 2 works with vim A and C and D but not B.  The
> > > number of directories could potentially be 2^N where N is the
> > > number of forks.  And who's going to do the necessary testing
> > > across multiple versions?  And remember that each minor version
> > > bump of any of the forks could render another fork's plugin
> > > incompatable.  This is a classic "moving target".  The only way
> > > that works is to have each fork look after their own copies of
> > > plugins.  
> > 
> > If and when that happens:  
> 
>   It already has happened.  Compare /usr/portage/app-editors against
> http://texteditors.org/cgi-bin/wiki.pl?ViFamily  Portage has...
> 
> * elvis
> * levee
> * nvi
> * vi
> * vim
> * vis
> 
> ...not to mention neovim, which doesn't show up on texteditors.org.

And none of the rest of those are Vim compatible, or support Vim's
scripting language. NeoVim is the only one that does, and only because
it's effectively a fork.

>   This would require a multi-dimensional array of approx 7 packages
> (today) versus however many ebuilds are currently in Portage for each
> editor.  Do I see any volunteers for compatibility testing for all
> current and future VI-family editors and plugins on all current and
> future ebuilds on all arches (small and large endian) and various USE
> flags?

You appear to be confusing vi and vim.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-06-02 Thread Ciaran McCreesh
On Fri, 2 Jun 2017 14:56:42 + (UTC)
Martin Vaeth <mar...@mvath.de> wrote:
> Most examples mentioned earlier were actually 2SAT, i.e.,
> they are only of the form foo? ( bar ) (possibly with negations)
> or can be easily reduced to that. E.g.
> ^^ ( foo bar )
> foo? ( !bar graulty bazola )
> can be rewritten as 2 or 3 2SAT-clauses as above, respectively.
> 
> For 2SAT, there are linear time algorithms.

You're getting the encoding wrong. "foo? ( bar )" does not encode as
"( !foo \/ bar )", because that would permit the solver to turn on bar
even if there is no need to do so.

Good luck figuring out how to encode grounding in SAT...

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

2017-06-01 Thread Ciaran McCreesh
On Thu, 1 Jun 2017 09:38:01 -0400
"Walter Dnes" <waltd...@waltdnes.org> wrote:
> On Wed, May 31, 2017 at 11:54:59PM +0100, Ciaran McCreesh wrote
> > - Have a separate anyvimishthing directory, and make both vim and
> > neovim look there, and only make plugins that have been tested to
> > work with both install to that directory.  
> 
>   As mentioned elsewhere, what happens when two or three other people
> do their own forks?

Nothing, unless those forks obtain large user bases, and then the issue
gets revisited. This is unlikely to happen.

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

2017-05-31 Thread Ciaran McCreesh
On Thu, 01 Jun 2017 07:00:30 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> > - Have a separate anyvimishthing directory, and make both vim and
> > neovim look there, and only make plugins that have been tested to
> > work with both install to that directory.
> 
> ...and then vimthreesome for things that work with three vim
> implementations?

If that ever happens, which is fairly unlikely, then revisit the
problem then, rather than adding unnecessary complexity now just in
case.

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] NeoVim and vim-syntax

2017-05-31 Thread Ciaran McCreesh
On Thu, 01 Jun 2017 02:32:24 +0700
"Vadim A. Misbakh-Soloviov" <gen...@mva.name> wrote:
> - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all
> the installed files
> 
> - patching NeoVim source to include Vim's runtimedirs (incl. "after"
> dir), // NeoVim upstream highly disagree with such way, if any
> 
> - patching VIMRUNTIME environment variable,
> 
> - making a wrapper,
> 
> - rewrite all the existing ebuilds to take nvim into account and
> force all newcomers to also take it,
> 
> - symlinking a directory,
> // mostly bad way, since opposite plugin compatibility is not
> garanteed and users can install nvim-only plugins in the future
> 
> - making postinst hook to regenerate content of NeoVim's
> site-directory (maybe, by symlinking installed vim modules there)
> 
> or even:
> 
> - making eselect module for user to rule that.

- Have a separate anyvimishthing directory, and make both vim and
neovim look there, and only make plugins that have been tested to work
with both install to that directory.

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-31 Thread Ciaran McCreesh
On Wed, 31 May 2017 21:02:24 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> No, it can't. That's the whole point. The algorithm must be defined so
> that it is always predictable independently of order

So what's this mysterious algorithm then?

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-31 Thread Ciaran McCreesh
On Wed, 31 May 2017 09:35:04 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> On śro, 2017-05-31 at 08:24 +0100, Ciaran McCreesh wrote:
> > On Wed, 31 May 2017 08:55:17 +0200
> > Michał Górny <mgo...@gentoo.org> wrote:  
> > > For example:
> > > 
> > >   foo? ( bar )
> > > 
> > > would mean 'if you have USE=foo, then USE=bar is enabled as
> > > well'.  
> > 
> > What about "if bar cannot be enabled, then turn foo off"?
> 
> Not expressible. The best you can do is 'if bar is disabled, ...'

This is the kind of thing that gets very messy when a user wants ssl
enabled, and has to enable either openssl or libressl, and they're on a
profile where openssl is masked but the ebuild writer prefers that
option...

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-31 Thread Ciaran McCreesh
On Wed, 31 May 2017 08:55:17 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> For example:
> 
>   foo? ( bar )
> 
> would mean 'if you have USE=foo, then USE=bar is enabled as well'.

What about "if bar cannot be enabled, then turn foo off"?

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-30 Thread Ciaran McCreesh
On Tue, 30 May 2017 10:46:54 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> On Tue, 30 May 2017 09:22:45 +0100
> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> > On Tue, 30 May 2017 09:42:45 +0200
> > Alexis Ballier <aball...@gentoo.org> wrote:  
> > > Oh crap, this requires to solve SAT.
> > 
> > The main problem would not be solving SAT, in this case. The problem
> > is providing the right answer when not enough information is given.
> > Spitting out a resolution which satisfies every dependency isn't
> > typically that difficult. Spitting out a resolution which doesn't
> > just turn off all your use flags and uninstall most of your programs
> > is the hard part.  
> 
> I don't really understand here: Assuming the formula is reduced where
> user-set useflags and profile-masked/forced ones are already assigned
> their true/false values, this leaves a formula with variables where
> changing any of those won't turn off (or on) anything you didn't want.
> If you can solve SAT on this reduced instance then you're safe, aren't
> you ?

First problem: encoding "don't change this from its current setting
unless you have a reason to do so" is an utter pain in SAT. There are
other models like ASP that can just about get around this, but
expressing it properly is best done by just writing your own solver.
Remember that you have to allow the solver to toggle some flags, so you
can't just lock everything, but at the same time, you don't want the
solver to randomly toggle a flag that isn't specified by the user or
the profile, unless it absolutely has a good reason to do so.

Second problem: a solver will spit out an arbitrary solution. If the
user then runs it again, there's no guarantee that it will spit out the
same arbitrary solution. That can be addressed by the right choice of
restart policies and tiebreaking etc if you're prepared to muck around
with the solver enough. But even if you do, suppose the user thinks
"yes, that's almost fine, but let me change one other thing" (or if
the install fails half-way through and the user tries to carry on after
fixing it). The solver will then spit out a totally different arbitrary
solution that looks nothing like the first one.

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-30 Thread Ciaran McCreesh
On Tue, 30 May 2017 09:42:45 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> Oh crap, this requires to solve SAT.

The main problem would not be solving SAT, in this case. The problem is
providing the right answer when not enough information is given.
Spitting out a resolution which satisfies every dependency isn't
typically that difficult. Spitting out a resolution which doesn't
just turn off all your use flags and uninstall most of your programs is
the hard part.

> Not hard as in you need a Ph.D. in algorithms to solve it but the
> kind of hardness almost every cryptographic algorithm used today, and
> in the foreseeable future, relies on.

Hrm, you're a bit off, there. SAT solving in practice isn't usually
that bad unless either your inputs are huge or they're deliberately
crafted to be ultra-nasty. Being NP-complete just means that instances
that will hit exponential behaviour exist, not that those instances
will occur in the application area you care about.

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Ciaran McCreesh
On Tue, 30 May 2017 00:01:16 +0200
Ulrich Mueller <u...@gentoo.org> wrote:
> >>>>> On Mon, 29 May 2017, Michał Górny wrote:  
> > On pon, 2017-05-29 at 20:00 +0200, Alexis Ballier wrote:  
> >> Can you provide an efficient algorithm for the above syntax? That
> >> is, given a set of +/- useflags forced by user, output the set of
> >> effective useflags (or a rant if it is inconsistent).  
> 
> > I'd rather leave that to people who are good with algorithms. I find
> > the whole thing scary but I don't really see a sane alternative
> > here. Worst case, we have to figure out some arbitrary limitations
> > to keep things sane.  
> 
> IMHO the sanest alternative would be to restrict the syntax to USE
> conditional forms which have an obvious solution. One of the many
> problems of REQUIRED_USE is that it sometimes requires solving a
> Zebra Puzzle.

Solving zebra puzzles isn't really that bad in practice most of the
time. The tricky bit is finding the *right* solution, given poor input
data that doesn't really let you evaluate what right is. As a simple
example, in the olden days, the most obvious and shortest answer to
fixing Gnome resolution errors was to set USE=mips because that
disabled a whole load of browser dependencies...

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Ciaran McCreesh
On Mon, 29 May 2017 23:23:55 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> > Can you provide an efficient algorithm for the above syntax?
> > That is, given a set of +/- useflags forced by user, output the set
> > of effective useflags (or a rant if it is inconsistent).  
> 
> I'd rather leave that to people who are good with algorithms. I find
> the whole thing scary but I don't really see a sane alternative here.
> Worst case, we have to figure out some arbitrary limitations to keep
> things sane.

That bit is NP-complete by an easy reduction from SAT. That isn't
necessarily a problem, because resolution isn't even in NP yet we're
still managing to spit out decent answers most of the time. Rather, the
difficulty lies in spitting out a *good* solution to the problem from
a user's perspective, and that's something that can't be done without
extremely high quality inputs.

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Ciaran McCreesh
On Mon, 29 May 2017 21:42:33 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> On pon, 2017-05-29 at 20:24 +0100, Ciaran McCreesh wrote:
> > On Mon, 29 May 2017 17:33:13 +0200
> > Michał Górny <mgo...@gentoo.org> wrote:  
> > > For a long time we seem to be missing appropriate tools to handle
> > > USE flag constraints efficiently. EAPI 4 brought REQUIRED_USE but
> > > all things considered, it has proven to be far from an optimal
> > > solution. I would therefore like to discuss adding a better tool
> > > to amend or replace it, to allow for automated handling of USE
> > > flag constraints.  
> > 
> > REQUIRED_USE's problems all come from it being thrown in at the last
> > minute without any testing of either the user experience or the
> > feasibility of its implementation. Have you implemented a prototype
> > to show that you can actually fix those problems?
> 
> I tend to RFC before starting the implementation. Saves effort.

Not the implementation. A prototype implementation. As we saw from
REQUIRED_USE, it really doesn't save effort to spend time specifying
something that can't even remotely work...

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

2017-05-29 Thread Ciaran McCreesh
On Mon, 29 May 2017 17:33:13 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> For a long time we seem to be missing appropriate tools to handle USE
> flag constraints efficiently. EAPI 4 brought REQUIRED_USE but all
> things considered, it has proven to be far from an optimal solution.
> I would therefore like to discuss adding a better tool to amend or
> replace it, to allow for automated handling of USE flag constraints.

REQUIRED_USE's problems all come from it being thrown in at the last
minute without any testing of either the user experience or the
feasibility of its implementation. Have you implemented a prototype to
show that you can actually fix those problems?

-- 
Ciaran McCreesh



Re: [gentoo-dev] Reverse use of Python/Ruby versions

2017-04-10 Thread Ciaran McCreesh
On Tue, 11 Apr 2017 02:31:54 +0700
"Vadim A. Misbakh-Soloviov" <gen...@mva.name> wrote:
> > If Java can do it, so can others.  
> 
> And here I come with my 5¢. And my point here is simple:
> 
> No, Java (Team) can't.

Ah, you appear to be thinking of the Gentoo Java team as it currently
exists, rather than the mythical perfect Gentoo Java team that existed
ten years ago and which will rise again soon, which is what William
meant.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Proposal: profiles/arches.desc - improve repoman flexibility (with other benefits)

2017-03-26 Thread Ciaran McCreesh
On Sun, 26 Mar 2017 13:04:18 -0700
Brian Dolbec <dol...@gentoo.org> wrote:
> While this is a simple format.  This is not a standard data input file
> format for language tools to map it into native language variables and
> types.
> 
> I would much prefer for any new files to be created in a format that
> most languages have data input modules for and are easily read/edited
> by humans.  While this can be read and split easily in python code.
> It is not future proof for additional data being added and/or removed.
> 
>  For the repoman stage3 rewrites. I am moving all configurable data
>  from the code into yaml based files in /metadata/repoman.  These
> files will be easily edited by all developers for updates to banned
> eclasses and various other values not needing code changes.   
> 
> So with a general file name of arches.desc  Is there any other data
> that we want to include in that file?  Possibly migrated from other
> file(s).  In that case a dictionary format yaml file might be best.
> My example below has additional info over what was proposed.  
> It is an example only to show the possible benefit of such a file
> type.

It's bad enough that we have to parse XML inside the package mangler for
optional data. Adding YAML (with all its format bugs: YAML files
created with libyaml can't be read by syck, and vice-versa) for files
that the package mangler has to read is even worse.

Plain text *is* a standard format.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

2017-03-23 Thread Ciaran McCreesh
On Thu, 23 Mar 2017 22:37:49 +0100
Alexis Ballier <aball...@gentoo.org> wrote:
> On Thu, 23 Mar 2017 20:30:40 +
> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> > On Thu, 23 Mar 2017 21:22:54 +0100
> > Alexis Ballier <aball...@gentoo.org> 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.
> > 
> > The original wording should probably have been something like "may
> > or may not exist, so ebuilds MUST NOT go poking around for it", but
> > the original wording was written assuming reasonable behaviour from
> > developers, and we deliberately chose not to go the SHALL, MUST NOT
> > route because of the added cost of developing a specification that's
> > safe from hostile implementers.
> 
> "reasonable" is not something that can be reasonably defined :)

There's a fairly good rule of thumb: is anyone else already doing this
horrible new thing you're about to add to the tree? If not, it's
probably not reasonable.

> after a few dozens of emails, what i understand of the issue is:
> autoconf assumes either the eblit stuff is in the environment, or
> FILESDIR variable is empty or points to its files dir; this might be
> borderline but definitely not hostile.

No, the issue is that eblits are a dodgy mechanism that go beyond what
ebuilds are supposed to do and that cause problems for package
manglers. When we're working with a general purpose shell underneath,
it's very hard to write a specification that can preemptively forbid
every kind of perverse mess any developer can come up with,
particularly when the developer starts looking for loopholes like
claiming it's OK to try to access a directory which is defined as
potentially not existing when the clear intent of the specification is
that "the directory isn't guaranteed to be there so don't try to use
it for anything".

> this breaks in the (hypothetical?) case where the package is installed
> from a binpkg *and* the binpkg format does not include the whole
> environment but rather a verbatim copy of the ebuild and its
> eclasses(*).
> 
> (*) not sure how that can even work with env saving between phases but
> that's not the point

It can't, so that weird hypothetical is irrelevant. But more to the
point, we're only wondering about these weird hypothetical situations
because someone felt the need to make everyone's life a misery by
putting some special snowflake code in the tree.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

2017-03-23 Thread Ciaran McCreesh
On Thu, 23 Mar 2017 21:22:54 +0100
Alexis Ballier <aball...@gentoo.org> 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.

The original wording should probably have been something like "may or
may not exist, so ebuilds MUST NOT go poking around for it", but the
original wording was written assuming reasonable behaviour from
developers, and we deliberately chose not to go the SHALL, MUST NOT
route because of the added cost of developing a specification that's
safe from hostile implementers.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

2017-03-23 Thread Ciaran McCreesh
On Thu, 23 Mar 2017 20:49:15 +0100
Alexis Ballier <aball...@gentoo.org> wrote:
> On Thu, 23 Mar 2017 19:17:43 +
> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> > On Thu, 23 Mar 2017 20:12:04 +0100
> > Alexis Ballier <aball...@gentoo.org> wrote:  
> > > However, retroactively adding new rules
> > 
> > Which, as you've already been told, is not what happened. Sit back,
> > enjoy the tree getting slightly less terrible, and stop trying to
> > find alternative facts to justify standing in the way of progress.
> >   
> 
> I'm sorry but forcing people to rewrite working stuff for no reason is
> not progress.

There is plenty of reason, and there is no forcing.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

2017-03-23 Thread Ciaran McCreesh
On Thu, 23 Mar 2017 20:12:04 +0100
Alexis Ballier <aball...@gentoo.org> wrote:
> However, retroactively adding new rules

Which, as you've already been told, is not what happened. Sit back,
enjoy the tree getting slightly less terrible, and stop trying to find
alternative facts to justify standing in the way of progress.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

2017-03-23 Thread Ciaran McCreesh
On Thu, 23 Mar 2017 19:52:13 +0100
Alexis Ballier <aball...@gentoo.org> wrote:
> > Do you think really think it's fine for maintainer to:
> > 
> > 1. go against best practices, principle of least surprise and
> > basically make it harder for anyone else to touch the ebuild (-> aim
> > for bus factor of 1 and/or making himself indispensable)?  
> 
> This is very (too) subjective.

It's really not. eblits are the result of vapier being vapier, and just
shoving stuff into the tree without review rather than doing things
properly. This stuff matters: Gentoo needs to be actively improving the
quality of the tree so that progress can be made, not fighting a losing
battle to stop it from getting even worse.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

2017-03-23 Thread Ciaran McCreesh
On Thu, 23 Mar 2017 19:41:01 +0100
Alexis Ballier <aball...@gentoo.org> wrote:
> > 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.
> >   
> 
> Continuing to be the devil's advocate, it seems adding '&& -d
> ${FILESDIR}' to that if would fix the issue too. At least with all
> currently approved EAPIs.

Please stop. PMS was not written with the kind of resources needed to
deal with people deliberately trying to find loopholes.

-- 
Ciaran McCreesh



Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

2017-03-02 Thread Ciaran McCreesh
On Thu, 2 Mar 2017 16:25:54 -0500
Michael Orlitzky <m...@gentoo.org> wrote:
> 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.

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.

-- 
Ciaran McCreesh



Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

2017-03-02 Thread Ciaran McCreesh
On Thu, 2 Mar 2017 09:47:35 -0500
Michael Orlitzky <m...@gentoo.org> wrote:
> 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.

Actually you can't have nice things because the labels proposal was
voted down for "being invented by the wrong people".

-- 
Ciaran McCreesh



Re: [gentoo-dev] Removal of CVS headers

2017-02-26 Thread Ciaran McCreesh
On Sun, 26 Feb 2017 21:16:28 +0100
Lars Wendler <polynomia...@gentoo.org> wrote:
> How about QA finally starts acting on useful issues or at least do
> actions that make sense?

Part of the job of QA is to improve the overall quality of the tree.
This includes going through and fixing historical mistakes. You may
think it's not important, but if Gentoo finally gets into the habit of
ongoing improvements, the tree will slowly get better rather than
worse over time.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Printer drivers and net-print

2017-02-23 Thread Ciaran McCreesh
On Thu, 23 Feb 2017 23:58:50 +0300
Andrew Savchenko <birc...@gentoo.org> wrote:
> On Thu, 23 Feb 2017 18:50:45 +0100 Ulrich Mueller wrote:
> > >>>>> On Thu, 23 Feb 2017, Andrew Savchenko wrote:  
> > >> https://projects.gentoo.org/pms/6/pms.html#x1-180003.1.1
> > >> "Category Names"  
> >   
> > > I don't see a requirement here, only note on most common
> > > pattern:  
> >   
> > > ``Note: A hyphen is not required because of the virtual category.
> > > Usually, however, category names will contain a hyphen.''  
> > 
> > It is a note on what is the exclusive pattern, with the single
> > exception of the virtual category. I believe that we shouldn't break
> > that pattern.  
> 
> I'm fine with this approach, but could PMS be updated to contain
> more clear statement to avoid misunderstanding? E.g.:
> ``all category names must contain a single hyphen with a
> special exception for "virtual"''

It's not a "must". Also, putting that rule in and having the package
mangler enforce it can have unintended consequences: for example,
there used to be the mild nuisance of dealing with overlays which
didn't contain a categories list, and which did contain directories
named CVS all over the place.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: The changes about the stabilization process

2017-01-02 Thread Ciaran McCreesh
On Tue, 3 Jan 2017 05:56:56 +1300
Kent Fredric <ken...@gentoo.org> wrote:
> On Thu, 29 Dec 2016 17:23:58 +
> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> 
> > Because it isn't... Are set names atoms? Are package names without
> > an associated category atoms?  
> 
> If I use the content of man 5 ebuild as a guide, I'd say no, sets
> can't be atoms.

What about if you read the user-oriented documentation, which has a
different semi-definition?

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: The changes about the stabilization process

2016-12-29 Thread Ciaran McCreesh
On Thu, 29 Dec 2016 13:28:12 +0100
Marc Schiffbauer <msch...@gentoo.org> wrote:
> "atom" is a well defined term in the gentoo world, so why not use it?

Because it isn't... Are set names atoms? Are package names without an
associated category atoms?

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: The changes about the stabilization process

2016-12-29 Thread Ciaran McCreesh
On Thu, 29 Dec 2016 16:44:12 +0100
Jeroen Roovers <j...@gentoo.org> wrote:
> On Wed, 28 Dec 2016 22:31:19 +
> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> > We made a deliberate decision not to use the word "atom" in PMS
> > because it means subtly different things in different contexts.  
> 
> You're doing it again! You're not citing any decisions on actual
> mailing lists, chat logs or in documentation, and you use
> qualifications like "subtl[e]" to denote some deeper rationale that
> is apparently very difficult to explain to the "uninitiated". Good
> job, if your job was to deter the "uninitiated".
> 
> Where was that decision recorded? What subtle differences did you
> perceive? Which contexts lead to those different meanings, and why did
> you not keep "atom" and qualify it according to context? Did you
> document the history, present and future of the term "atom" so you
> could point out why it was rejected for future use? Even, what
> real-world problem were you trying to solve in rejecting "atom"?

Unfortunately we had a team of three when writing PMS to begin with,
and the emphasis was on producing a definitive spec, not a history book.
We did not have a volunteer archivist at the time. If you'd like to
volunteer to start, I'm sure you'd be welcome to produce an annotated
PMS for people who are interested in that kind of thing -- the
annotated C++ reference manual was a lovely read, back when it was
maintained.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: The changes about the stabilization process

2016-12-28 Thread Ciaran McCreesh
On Wed, 28 Dec 2016 23:21:51 +0100
Jeroen Roovers <j...@gentoo.org> wrote:
> On Thu, 29 Dec 2016 03:49:30 +1100
> Michael Palimaka <kensing...@gentoo.org> wrote:
> > > Can you please avoid reintroducing the term "atom" there, when we
> > > are trying to get rid of it elsewhere [1]? Note that PMS doesn't
> > > define the term [2].
> > 
> > Any suggestions for improved text? Ideally it would be
> > stabilisation/keywording agnostic as the same field is used in both
> > components.  
> 
> How about "atoms". We've been using that for ages (regardless of what
> PMS authors think) so why change it now? Alternatively, I would
> propose to call them "bikesheds" as that will work just as well as
> any other label and will succinctly refer to the creative process
> that made it a replacement for "atoms".

We made a deliberate decision not to use the word "atom" in PMS because
it means subtly different things in different contexts.

-- 
Ciaran McCreesh



Re: [gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash

2016-12-05 Thread Ciaran McCreesh
On Sun, 4 Dec 2016 18:47:48 -0800
Daniel Campbell <z...@gentoo.org> wrote:
> Compliance with what? If others desire Quickbook support, they can
> make a tool to convert from ledger. There's no good reason for a
> non-profit, libre software organization to use and depend on
> proprietary software. Did nobody learn a lesson from BitKeeper?

Have you checked that the people hosting Gentoo's infrastructure don't
use any proprietary software anywhere inside their building either? Most
cleaning companies use a closed source staff scheduling program. It
would be a terrible violation of the social contract if Gentoo depended
upon that.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Uppercase characters in package names

2016-12-02 Thread Ciaran McCreesh
On Fri, 2 Dec 2016 13:24:29 -0500
Mike Gilbert <flop...@gentoo.org> wrote:
> On Fri, Dec 2, 2016 at 1:10 PM, Ciaran McCreesh
> <ciaran.mccre...@googlemail.com> wrote:
> > On Fri, 2 Dec 2016 13:02:48 -0500
> > Mike Gilbert <flop...@gentoo.org> wrote:  
> >> The devmanual states:
> >>
> >> The name section should contain only lowercase non-accented
> >> letters, the digits 0-9, hyphens, underscores and plus characters.
> >> Uppercase characters are strongly discouraged, but technically
> >> valid.
> >>
> >> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> >>
> >>
> >> Why are uppercase characters strongly discouraged?
> >>
> >> Wouldn't it make sense to follow upstream's naming convention?  
> >
> > What's upstream's naming convention for Firefox?
> 
> I have no idea. What's your point?

That naming conventions are generally complicated and a mess, and that
no-one wants to have to remember whether it's firefox, Firefox, or
FireFox.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Uppercase characters in package names

2016-12-02 Thread Ciaran McCreesh
On Fri, 2 Dec 2016 13:02:48 -0500
Mike Gilbert <flop...@gentoo.org> wrote:
> The devmanual states:
> 
> The name section should contain only lowercase non-accented letters,
> the digits 0-9, hyphens, underscores and plus characters. Uppercase
> characters are strongly discouraged, but technically valid.
> 
> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> 
> 
> Why are uppercase characters strongly discouraged?
> 
> Wouldn't it make sense to follow upstream's naming convention?

What's upstream's naming convention for Firefox?

-- 
Ciaran McCreesh



Re: [gentoo-dev] Developer GitHub usernames

2016-11-21 Thread Ciaran McCreesh
On Mon, 21 Nov 2016 21:28:33 +0100
Jeroen Roovers <j...@gentoo.org> wrote:
> On Mon, 21 Nov 2016 10:01:47 +0100
> Michał Górny <mgo...@gentoo.org> wrote:
> 
> > Since some of our people don't want to admit they're using GitHub or
> > otherwise want to pretend they're not  
> 
> Interesting how you simply can't understand that some people hate
> mixing work and pleasure[1] and how you then need to ridicule what you
> don't understand, Ciaran.

Wait what. Why am I being blamed for any of this? I assure you, Michał
isn't one of my sockpuppet developer accounts, and my involvement with
Github as a company is limited to them buying me an awful lot of
free booze once. I think you might be seeing conspiracies in the
wrong place...

-- 
Ciaran McCreesh



Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

2016-10-24 Thread Ciaran McCreesh
On Mon, 24 Oct 2016 15:34:14 -0700
Matt Turner <matts...@gentoo.org> wrote:
> In order to contribute to GNU projects, one must sign a copyright
> assignment statement.
> 
> Gentoo doesn't have anything similar as far as I'm aware, which makes
> me question the legitimacy of "Gentoo Foundation" copyrights.
> 
> What is the story?

Gentoo did have a copyright transfer agreement at one point, which was
written by an actual paid-for lawyer. Developers had to agree to hand
over their floppy disks and monitors to the Foundation upon request.
Developers who were recruited in a particular time window had to sign
it, but anyone who started before didn't.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Package file name requirement for binary ebuilds

2016-10-18 Thread Ciaran McCreesh
On Mon, 17 Oct 2016 16:43:40 -0400
"William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
> No its a PMS requirement as you said not visual as I was saying...

PMS doesn't cover multiple repository stuff in much detail. We didn't
want to mandate Portage's historical weird overlay behaviour, so it
doesn't really specify anything at all.

-- 
Ciaran McCreesh



Re: [gentoo-dev] New Working Group established to evaluate the stable tree

2016-08-14 Thread Ciaran McCreesh
On Sun, 14 Aug 2016 23:35:58 +0200
Kristian Fiskerstrand <k...@gentoo.org> wrote:
> During the latest Council meeting it was determined to set up a new
> Working Group to come up with recommendations for improving the state
> of the stable tree at a later Council meeting.

What's a Working Group, and how is it related to a Project? Shouldn't
there be a GLEP to define what a Working Group is first?

-- 
Ciaran McCreesh



Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

2016-08-11 Thread Ciaran McCreesh
On Thu, 11 Aug 2016 17:57:59 +0300
Mart Raudsepp <l...@gentoo.org> wrote:
> I strongly believe that it's important to have such a use case as
> Steam work problem-free in Gentoo.

Steam isn't a use case, it's a program.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: Packages up for grabs

2016-08-07 Thread Ciaran McCreesh
On Sun, 7 Aug 2016 12:24:37 -0500
james <gar...@verizon.net> wrote:
> >> Let them use java* codes, as that is what all the universities are
> >> teaching and promoting. I agree
> >> with gentoo proper on severely restricting java*,  on
> >> gentoo-proper, but that sort of thing is killing gentoo and just
> >> appears to the open world as a filter mechanism to keep out and go
> >> elsewhere, snoot. There are just too many exciting and useful
> >> codes out there running java.  
> >
> > "All" ? Some. And the dominance and focus on Java is itself telling
> > of the quality and type of the education provider.
> >
> > Some education providers may not touch Java at all, and focus
> > predominantly on C.  
> 
> Sure, I agree here, but, statistically these "hi level" languages are 
> being taught, in lieu of C; and that is really sad. I'm sure there
> are exceptions, would you have a few CS departments that push C over
> java and the other, newer languages? (I'm curios).

You all appear to be missing the point of education. If you are learning
technologies, your skills will be obsolete in five years. If you are
learning general principles and problem solving, the particular
language being used is much less important.

-- 
Ciaran McCreesh



Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

2016-07-24 Thread Ciaran McCreesh
On Sun, 24 Jul 2016 10:17:24 +0200
Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> wrote:
> > Then ebuilds will fail just the same  
> 
> No. Before, ebuilds would maybe display an upgrading message when
> they shouldn't, or vice versa. Now the eclass dies on them.

This attitude that invisible failures (which don't get fixed, and which
lead to occasional weirdness) are better than visible failures (which
must be fixed) is an odd one... Postel has a lot to answer for.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

2016-07-24 Thread Ciaran McCreesh
On Sun, 24 Jul 2016 10:05:23 +0300
Andrew Savchenko <birc...@gentoo.org> wrote:
> I agree with you, but REPLACING_VERSIONS has nothing to do with
> such recovery.

Yes, it does. Specifically, what we want is for developers to get into
the habit of writing safe, clean code, even if they think they don't
need to care about it in some particular situation because they can't
think of how it would go wrong. It's the same as getting into the habit
of sticking || die on things.

> 1) It appeared only in EAPI 4, approved on 2011-01-17. Recovery
> from hardware crashes forked well long before.

Before this, you could use has_version in pkg_*, and it would tell you
the *old* version of the package that was installed. The phase order
changed a while ago, and broke this, so REPLACING_VERSIONS was the
replacement.

Again, the situation is complicated, there's a lot of messy history
behind this, and if you don't know it all, just do what the spec says
and stop wasting everyone's time by arguing.

> 2) If you will look into the tree, in the absolute majority of cases
> REPLACING_VERSIONS is being used to determine whether informational
> messages should be shown to a user or not. Such messages usually
> include some upgrade hints or howtos; and REPLACING_VERSIONS check
> is required to avoid showing them to unaffected users. It has
> absolutely nothing to do with the error recovery done by PM itself.

Don't get into the habit of writing code that makes unnecessary
assumptions that will come back and screw users over in unexpected
situations. It's easy to do this the right way, so at this point I can
only conclude that you're persisting in trying to do it wrong just to
avoid admitting that you made a mistake from ignorance. It's OK to be
wrong sometimes (and this is why code review exists), but it's not OK
to continue to argue that you were right out of stubbornness.

-- 
Ciaran McCreesh



Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

2016-07-23 Thread Ciaran McCreesh
On Sun, 24 Jul 2016 00:04:53 +0200
"Andreas K. Huettel" <dilfri...@gentoo.org> wrote:
> 1) If a package only ever had one slot, it cannot ever have two
> versions installed at the same time. That guarantee (of only ever one
> slot) can be given for the portage tree (sic). Obviously it doesn't
> work for overlays, but there are many things we don't care about for
> overlays. [A]

Outright wrong, as has already been explained in this thread several
times.

> 2) If a package manager leaves two versions of a non-slotted package 
> "installed" somehow, that package manager is fundamentally broken and
> its author should forever refrain from specifying anything. It's not
> our job to work around Paludis failure modes. [B]

This is not a Paludis issue. It happens with Portage too. The install
sequence is carefully designed to install the new version of the
package, and then remove the old one (and if you think about it for a
few seconds, you can see that it *has* to be this way). If an error or
ctrl+c occurs at the wrong point, both versions remain installed, and
importantly, there is a safe way to recover from this.

-- 
Ciaran McCreesh



Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

2016-07-23 Thread Ciaran McCreesh
On Sun, 24 Jul 2016 00:30:39 +0300
Andrew Savchenko <birc...@gentoo.org> wrote:
> Oh, nice: strictly follow PMS no matter what, right? Then let me
> remind you that not so long time ago I advocated for strictly
> following PMS [1,2], which _allows_ || ( A:= B:= ) construct [3].
> 
> But I was _enforced_ by QA to _violate_ PMS and remove the valid
> syntax blocks [4]. This decision was made because of $reasons:
> - we lack ||= operator;
> - || ( := ) behaviour is not implemented properly in existing PM;
> - "it doesn't make *any* sense";
> - other valid and unquestionable $reasons ...
> 
> So the result is that common sense and practical considerations
> take over PMS. And what we have in the REPLACING_VERSIONS case?
> It doesn't matter that such situation never happened and will
> likely never happen, but one must follow PMS strictly no matter
> what. Such attitude is not fair at least.

No. You have simply failed to understand the reason || ( A:= B:= )
doesn't work. It may superficially appear correct, but you either need
to think carefully about the implications, or just accept wisdom from
people who have. I remind you that PMS does not explicitly prohibit a
dependency upon =A-1 =A-2 where A is not slotted, either: it's a
nonsense dependency, but syntactically valid.

Please stop trying to use your common sense in areas where you lack the
intuition and experience to have accurate common sense.

> Do we ever had such case like multiple versions of the same
> single-slotted package installed or recorded as installed in the
> real world? I'm not sure even in this, but I may assume that it may
> happen one day.

Yes, this happens with failures on uninstalls and upgrades.

> Do we have any proof that PM can recover from such situation,
> where VDB is a mess and installed files can also be a mess? I'm not
> sure in this at all.

Yes, things have been designed quite carefully to allow this to happen.
You recover by installing a new version, and using it to replace the
two installed versions simultaneously.

> Do we have any test suits for portage (as the most popular PM
> implementation) for such cases? I doubt this, I can find none. I'm
> not sure if such tests are implemented in other PM test suits too.

Portage doesn't exactly have many tests...

-- 
Ciaran McCreesh



Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

2016-07-23 Thread Ciaran McCreesh
On Sat, 23 Jul 2016 17:23:48 +0300
Andrew Savchenko <birc...@gentoo.org> wrote:
> On Fri, 22 Jul 2016 14:57:36 +0100 Ciaran McCreesh wrote:
> > On Fri, 22 Jul 2016 16:41:56 +0300
> > Andrew Savchenko <birc...@gentoo.org> wrote:  
> [...]
> > > I see no point in trashing ebuilds with dead code that will never
> > > be used. Though if there will be a PMS or eclass function with
> > > "proper" implementation, I don't mind, since extra code will be
> > > moved from ebuild elsewhere.  
> > 
> > Slots are not the only way in which you can end up with multiple
> > installed versions of the same package. Another way is if there's a
> > fatal error during certain parts of the upgrade process.  
> 
> If setup is broken to the point when several version within single
> slot are installed (or are reported to be installed), then:
> 
> 1) There is no way to tell which version is valid and all of them
> may be invalid. That's why REPLACING_VERSIONS is of no use at all
> in such situation.
> 
> 2) System is severely broken and mistakenly shown (or not shown)
> ewarn message will be the least problem for a user of such system.

Uh, nope. The PM can recover from that situation, so long as people
don't go around writing broken ebuilds that make unwarranted
assumptions that the spec specifically tells them not to make. Don't
get into the habit of writing broken code.

Or to put it another way: you are wrong, and you don't know enough
about the situation to understand why you're wrong, and you clearly
have no interest in learning, so just do as you're told.

-- 
Ciaran McCreesh



Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

2016-07-22 Thread Ciaran McCreesh
On Fri, 22 Jul 2016 16:41:56 +0300
Andrew Savchenko <birc...@gentoo.org> wrote:
> On Fri, 22 Jul 2016 13:14:23 +0200 Michał Górny wrote:
> > Dnia 22 lipca 2016 13:00:42 CEST, Andrew Savchenko
> > <birc...@gentoo.org> napisał(a):  
> > >On Thu, 21 Jul 2016 07:12:12 +0200 Michał Górny wrote:  
> [...]
> > >> Few important QA notes:
> > >> 
> > >> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2
> > >> gives false,  
> > >
> > >Thanks, fixed.
> > >  
> > >> 2. REPLACING_VERSIONS can have more than one value,  
> > >
> > >While it can indeed, I see no way for this to happen if package
> > >hasn't and never had multiple slots.  
> > 
> > Wrong. PMS specifically requests you to account for such a
> > possibility.  
> 
> Common sence must prevail over formal approaches. While PMS is
> great, it is not perfect in all possible aspects, and this one is
> one of them.
> 

And this is a perfect example of why so much stuff in Gentoo is subtly
broken... Things are usually more complicated than you think, buggy code
usually works well enough that the mistakes aren't noticed in most
cases, and too many developers are far too convinced of their own
competence. You need to appreciate that you do not have a complete
understanding of what is going on, your "common sense" is leading you
astray, and that that API was designed the way it was out of necessity.

> I see no point in trashing ebuilds with dead code that will never
> be used. Though if there will be a PMS or eclass function with
> "proper" implementation, I don't mind, since extra code will be
> moved from ebuild elsewhere.

Slots are not the only way in which you can end up with multiple
installed versions of the same package. Another way is if there's a
fatal error during certain parts of the upgrade process.

-- 
Ciaran McCreesh



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-14 Thread Ciaran McCreesh
On Wed, 15 Jun 2016 00:21:45 +0200
"Andreas K. Huettel" <dilfri...@gentoo.org> wrote:
> Am Montag, 13. Juni 2016, 09:50:15 schrieb Alexander Berntsen:
> > > I still think you're underestimating the need for centralization.
> > > What you call a "core/base" package is probably going to end up
> > > being anything listed in a dependency.  That is a LOT of packages,
> > > actually - we're not just talking about libc and zlib.  
> > 
> > It's not a lot compared to how many we have today.  
> 
> Please do me a favor and emerge @system on a fresh stage
> installation, with USE=kde ...
> 
> ... So, 
> 
> * does KDE go into the curated repos? or
> * will the useflag functionality be discontinued?

* Your package mangler tells you you need some packages which can
be found in the ::kde repository if you have that flag enabled, and
suggests you either install repository/kde or disable that USE flag so
that it can continue.

-- 
Ciaran McCreesh



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Ciaran McCreesh
On Thu, 9 Jun 2016 14:25:08 +0200
Dirkjan Ochtman <d...@gentoo.org> wrote:
> I would tend to agree with those who have written that coordinating
> work across repos is kind of a pain.

How do you know? What is your experience in the area of coordinating
work across repos in a Gentoo-style distribution?

-- 
Ciaran McCreesh



Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-10 Thread Ciaran McCreesh
On Thu, 9 Jun 2016 06:20:38 -0400
Rich Freeman <ri...@gentoo.org> wrote:
> > On 08/06/16 16:53, Rich Freeman wrote:  
> >> Do you propose that you can have cross-repo dependencies?  
> > Sure. This works well in Exherbo using Paludis. We could do it
> > right now if we wanted to.
> >  
> >> If so that creates a lot of potential issues, even if you do it
> >> the NixOS way.  
> > You should tell Exherbo and NixOS about all these issues that they
> > should be having but aren't having.
> >  
> 
> Perhaps you could explain how they actually prevent the issues I
> brought up?  Since you didn't actually quote them I'll do so:
> 
> Suppose you have 10 packages, and they each depend on zlib from a
> different repository?

They don't. Packages do not depend upon "zlib from repository x". They
depend upon "zlib".

The Exherbo model is not "packages are all over the place and there is
no coordination whatsoever". The model is "packages that lots of people
use are in a small number of core repositories and are carefully dealt
with to avoid breakages, but packages that have small numbers of users
are in personal repositories which everyone can see". Libraries and
packages that start to be used by many people get moved to one of the
central repositories; one way to tell that this needs to be done is
when it looks like the issues you think could happen actually start to
happen.

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Global USE=gui

2016-06-10 Thread Ciaran McCreesh
On Fri, 10 Jun 2016 00:18:44 +0200
Ulrich Mueller <u...@gentoo.org> wrote:
> >>>>> On Thu, 9 Jun 2016, Michał Górny wrote:  
> >> That would be a policy violation. Packages should pick a reasonable
> >> default if flags are conflicting, but not force users to
> >> micro-manage their flags.  
> 
> > Who did establish that *idiotic* policy and why is he still a
> > developer?  
> 
> Michał,
> You may want to reconsider your tone.
> 
> The policy was established when documenting REQUIRED_USE for EAPI 4,
> and it is based on consensus in bug 353624 [1] and in the gentoo-dev
> mailing list [2,3].

Really, that policy predates REQUIRED_USE, and even EAPIs... In the
olden days, the rule was that USE flags were for things that were
optional, and that if something wasn't optional, then it shouldn't be
controlled by USE flags.

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] Global USE=gui

2016-06-07 Thread Ciaran McCreesh
On Tue, 7 Jun 2016 22:59:42 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> Not 5 minutes. Depending on the context, Portage can complain about
> REQUIRED_USE in a few seconds because it has no further point
> in evaluating the depgraph.

...but it shouldn't, because then it only gives you the first error.

-- 
Ciaran McCreesh



Re: [gentoo-dev] What are eblits?

2016-05-27 Thread Ciaran McCreesh
On Fri, 27 May 2016 00:28:35 +0200
rindeal <dev.rind...@gmail.com> wrote:
> 1) what are they?

A horrible QA violation.

> 2) why are they used?

Because some people like to feel special...

-- 
Ciaran McCreesh



Re: [gentoo-dev] Proposal for changes for the next EAPI version

2016-05-17 Thread Ciaran McCreesh
On Tue, 17 May 2016 07:26:03 -0400
Michael Orlitzky <m...@gentoo.org> wrote:
> We already have "emerge --config" which is expected to be run after
> the install process has completed, so I don't think that this is too
> much of a stretch. Maybe call the phase "pkg_test" analogous to
> "pkg_config" and in contrast to "src_test" which runs within the
> working directory. Then "emerge --test" could run it.

For various technical reasons to do with the spec and package manglers
sometimes using phase function names with the src_ or pkg_ stripped
off, calling it that would be a huge pain.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-05-16 Thread Ciaran McCreesh
On Mon, 16 May 2016 15:56:01 +0800
Ian Delaney <idel...@gentoo.org> wrote:
> As long as this persists and is not intervened to polish and tidy up,
> g-devs will persist in making innocent, naive or incompetent blunders
> and run the gauntlet of being publicly scolded over errata. I can only
> express my view that this style of personal demeaning potentially
> results in embarrassment, public humiliation and drives community
> members away from participation. The ultimate negative influence. I
> would never entertain taking on eclass writing with the incumbent qa
> member delivering assessments under the title of 'code review' in the
> style he does.

If you're writing the kind of code that results in you being subjected
to scathing criticism for breaking metadata generation for the entire
tree, then discouraging you from contributing can only be good for the
distribution...

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-05-14 Thread Ciaran McCreesh
On Sun, 15 May 2016 08:40:39 +0900
Aaron Bauman <b...@gentoo.org> wrote:
> Please enlighten me as to what was impolite here?  The strong
> language of "seriously" or definitively stating that the individual
> did not perform the necessary QA actions before committing?  Both of
> which are completely called for and appropriate.  No vulgarity,
> insults, or demeaning words were used. How would you have responded
> professionally?

It's important to remember that Gentoo is run by volunteers. Expecting
a professional standard when it comes to the quality of commit
criticism is unfair.

-- 
Ciaran McCreesh



Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2016-05-14 Thread Ciaran McCreesh
On Sat, 14 May 2016 11:55:42 +0200
> Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney:
> > On Sat, 7 May 2016 23:25:58 +0200  
> > > Do you seriously expect this code to work? How about testing? Or
> > > reading diffs before committing?  
> > 
> > Do you seriously expect us to sit and absorb this form of pious
> > put down? From one who knows far better who is entitled to speak
> > down to colleagues as is completely lacking a cerebral cortex?
> > Those times are drawing to an end. Did anyone ever teach you to
> > treat folk in such manner and expect them to respect it? I don't
> > think so Not over my dead cvs perhaps  
> 
> Well, we still do need some commit quality, you know...

Why? Gentoo is about the community. Requiring a basic standard of commit
quality a) reduces the number of community members who are able to
contribute, 2) leads to fewer forums posts discussing how to fix
problems, iii) hurts Gentoo's DistroWatch statistics by reducing the
volume of commits, and fourthly, discriminates unfairly against
competency-challenged developers by imposing subjective interpretations
of the value of source code from a position of unearned authority. This
is against the code of conduct, and is bad for the community!

-- 
Ciaran McCreesh



Re: [gentoo-dev] News Item: LastPass package migration

2016-05-08 Thread Ciaran McCreesh
On Sun, 8 May 2016 01:25:58 -0400
Göktürk Yüksek <gokt...@binghamton.edu> wrote:
> Display-If-Installed: app-admin/lastpass

Every version, forever, even for new installs made next year?

-- 
Ciaran McCreesh



Re: [gentoo-dev] Uncoordinated changes

2016-02-14 Thread Ciaran McCreesh
On Sun, 14 Feb 2016 19:53:56 +0100
Patrick Lauer <patr...@gentoo.org> wrote:
> I don't have time to follow every little change, so it's quite
> annoying to reverse-engineer this change that apparently is a
> compromise that no one actually wanted, and hasn't really been
> finished yet. Sigh.

Why reverse engineer it? It's all documented.

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

2016-01-19 Thread Ciaran McCreesh
On Tue, 19 Jan 2016 23:32:30 +0100
Michał Górny <mgo...@gentoo.org> wrote:
> The problem was, is and will be that packages are unmaintained. Not
> that stats show that they are many.

No it's not. Gentoo is about the community, and it's important for the
community not to perceive that there is a problem. Being honest where
users or Phoronix could pick up on it is bad PR. Let's not create a
toxic perception of the state of the tree.

-- 
Ciaran McCreesh



Re: [gentoo-dev] [RFC] ban use of base-4 casemods in ebuilds due to locale collation instability

2015-11-11 Thread Ciaran McCreesh
On Wed, 11 Nov 2015 07:16:42 +0100
Patrick Lauer <patr...@gentoo.org> wrote:
> Wouldn't it be 'easier' (fsov easy) to have portage use sane-default
> locale settings, so that estonian or turkish users don't get hit by
> weirdness in the [a-z] character class etc.?

Paludis forces all the LC variables to sane values. A few vocal
annoying users hate this, and patch it out...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Revision diffs

2015-11-06 Thread Ciaran McCreesh
On Sat, 7 Nov 2015 02:34:22 +1300
Kent Fredric <kentfred...@gmail.com> wrote:
> On 7 November 2015 at 02:16, Michael Orlitzky <m...@gentoo.org> wrote:
> > These days, if I'm careful to revbump when necessary AND limit my
> > commits to one logical change, can I wind up going from (say) -r1
> > all the way to -r4 before pushing my changes.
> 
> Personally I don't think that's necessary. The "-r bump on dep change"
> argument is a defence against installer limitations and the
> replication of changes to users.

No it isn't.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: ChangeLog

2015-11-02 Thread Ciaran McCreesh
On Mon, 2 Nov 2015 14:00:18 -0600
Dale <rdalek1...@gmail.com> wrote:
> Rich Freeman wrote:
> > On Mon, Nov 2, 2015 at 1:08 AM, Dale <rdalek1...@gmail.com> wrote:
> >> Then perhaps all this should have been worked out BEFORE switching
> >> to github?
> > We didn't switch to github.
> 
> Then why are people saying to use git to look at the logs?   I don't
> want to use git.

git != github...

> I liked being able to go to the tree and look at the
> change logs when I needed to which is sometimes often.

I think you have a technology comprehension problem here, rather than a
technology problem. The problem is your workflow, not the tools.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Depending on a range of slots

2015-11-02 Thread Ciaran McCreesh
On Mon, 2 Nov 2015 12:48:29 -0500
Michael Orlitzky <m...@gentoo.org> wrote:
> Is there a way to say "give me any 4.x or 5.x slot"?

No. Slots are meaningless strings and do not support any comparison
except equality.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Depending on a range of slots

2015-11-02 Thread Ciaran McCreesh
On Mon, 2 Nov 2015 14:33:57 -0500
Michael Orlitzky <m...@gentoo.org> wrote:
> Followup question, which of these is less dumb?
> 
> Option 1: berkdb? ( >=sys-libs/db-4:*   Option 2: berkdb? ( || ( sys-libs/db:4.2 ... sys-libs/db:5.3 ) )

Best option goes leftmost in ||.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Depending on a range of slots

2015-11-02 Thread Ciaran McCreesh
On Mon, 2 Nov 2015 22:01:05 +0100
hasufell <hasuf...@gentoo.org> wrote:
> That's an interesting pitfall. I am pretty sure we have this kind of
> syntax a lot in the tree. Might make sense to document it.

Would make more sense just to implement version ranges in full
generality, since developers seem to insist upon using < dependencies
anyway...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: ChangeLog

2015-11-01 Thread Ciaran McCreesh
On Sun, 01 Nov 2015 22:19:24 +0600
Мисбах-Соловьёв Вадим <m...@mva.name> wrote:
> > Now how can this user display the ChangeLog for
> > a certain package?
> ```
> git log -- pkg-category/pkg-name/
> ```
> // assuming user in portage directory or passed GIT_DIR with path to
> it.
> 
> Although, it is only if user has successfully cloned/synced the
> repo ;) Which is hardcore quest when you're living in, say, Syria,
> Egypt, Somalia, or something like that. Or, if you're, say, in
> transsiberian train ride for a week.

Perhaps there is a better choice of distribution for you if you are.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] News Item: Changes in default VIDEO_CARDS

2015-10-29 Thread Ciaran McCreesh
On Thu, 29 Oct 2015 17:13:29 +0100
Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> wrote:
> Ciaran McCreesh schrieb:
> > On Thu, 29 Oct 2015 16:22:40 +0100
> > Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> wrote:
> >> The previous time I wanted to post a news item with USE
> >> dependencies, this was not possible because the
> >> Display-If-Installed dependency atom had to conform to EAPI 0. But
> >> now that all profiles are EAPI 5 this is ok I hope.
> > It's not really clear what the EAPI for the news directory is...
> 
> I guess you are right, but as all package managers must now
> understand EAPI 5 dependency atoms, it is not likely that any will
> choke on it.

Well Portage won't, since it doesn't do input validation and will
pretty much allow you to use any EAPI's syntax anywhere. Paludis will
probably warn that you're using an EAPI 5 feature somewhere where EAPI
5 hasn't been declared, since everything that isn't explicitly a
particular EAPI is EAPI 0.

> Besides, existing news items already use
> Display-If-Profile: to point to EAPI 5 profiles.

That isn't how EAPIs work, conceptually. Whenever a PM does something
with a spec, it asks what the EAPI is in the context of that spec,
which in turn depends upon where that spec came from. A user using a
profile with EAPI 5 does not mean that every dep spec is treated as
being EAPI 5 -- the profile EAPI just applies to things from that
particular profiles directory. (And even if it did work the way you
think, users not using an EAPI 5 profile would still need to be able to
parse that news item...)

> But I can ask the Council for clarification on the issue.

Not so much a Council issue as a PMS one, but the trouble is that news
items slightly predate PMS and EAPIs.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] News Item: Changes in default VIDEO_CARDS

2015-10-29 Thread Ciaran McCreesh
On Thu, 29 Oct 2015 16:22:40 +0100
Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> wrote:
> The previous time I wanted to post a news item with USE dependencies, 
> this was not possible because the Display-If-Installed dependency
> atom had to conform to EAPI 0. But now that all profiles are EAPI 5
> this is ok I hope.

It's not really clear what the EAPI for the news directory is...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/

2015-10-21 Thread Ciaran McCreesh
On Wed, 21 Oct 2015 01:25:53 +0200
hasufell <hasuf...@gentoo.org> wrote:
> Also, my package manager chokes on it. Repoman not, so that looks
> like a bug.

s/Repoman/Portage/

Portage will quite happily let you specify KEYWORDS=":)".

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Ciaran McCreesh
On Sun, 18 Oct 2015 20:19:12 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> what I was trying to understand is what is the usefulness of eapply
> vs epatch

The point of eapply is that it's inside the package manager, so it can
safely be used by default phase functions, for user patches, etc.
Rather than it being a direct copy of the epatch API, we took this as
an opportunity to tidy up the behaviour to make it do something easy to
understand and sensible, rather than being full of scary voodoo
heuristics which are rarely necessary (and when they are, fixing your
patches is easy) and which have weird effects that you don't know
about until it's too late.

Of course, this is part of the larger debate on "as much as possible in
the PM" versus "as much as possible in the tree". The main "in the PM"
argument is "less breakage and better testing"; the main "in the tree"
argument is that things going spectacularly wrong for users every now
and again is fine because it lets developers have new useless toys
slightly faster. (This is a totally unbiased and entirely comprehensive
summary of the debate.)

> or simply using 'epatch "${PATCHES[@]}"' when proper patches do not
> fit in what you call 'all the useful features': I haven't seen any,
> so that I know where to stand on using that feature or not. It is
> simply inferior and deemed unfixable until next EAPI.

It would be nice if eutils defined epatch to die for EAPI 6...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Ciaran McCreesh
On Sun, 18 Oct 2015 10:31:09 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> > The rationale is that we cannot apply patches in the default
> > src_prepare() unless there is a patch function in the package
> > manager itself. Obviously the default phase cannot call a function
> > from an eclass.
> 
> well, that was the idea behind base.eclass :)
> why not just improving it ?

No, the idea behind base.eclass was that somehow ebuilds were "object
oriented", and that whenever you had "object oriented" you had to have
a single base class for everything.

It was a silly idea and we should all be glad it has been forgotten.

> - why should I ever want eapi6 src_prepare instead of
>   base_src_prepare ?

Well base.eclass is supposed to be being removed, and is allegedly
banned for all new ebuilds...

But the big gain for everyone is in replacing a weird, overly clever
and highly fragile collection of weirdness that's designed to mostly
accept any dodgy input, with one that just gets you to give it a sane
input to begin with.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-18 Thread Ciaran McCreesh
On Sun, 18 Oct 2015 20:00:11 +0200
Alexis Ballier <aball...@gentoo.org> wrote:
> On Sun, 18 Oct 2015 13:44:30 +0100
> Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> [...]
> > > - why should I ever want eapi6 src_prepare instead of
> > >   base_src_prepare ?  
> > 
> > Well base.eclass is supposed to be being removed, and is allegedly
> > banned for all new ebuilds...
> > 
> > But the big gain for everyone is in replacing a weird, overly clever
> > and highly fragile collection of weirdness that's designed to mostly
> > accept any dodgy input, with one that just gets you to give it a
> > sane input to begin with.
> > 
> 
> removing features is certainly not a gain for me
> 
> after all, the safest program is the one that does nothing

It's a good thing we've left in all the useful features, then.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

2015-10-17 Thread Ciaran McCreesh
On Sat, 17 Oct 2015 14:49:36 +0200
hasufell <hasuf...@gentoo.org> wrote:
> You can apply the patches post_unpack or post_src_prepare witht hooks.
> What's the problem?

Running autorecrap.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC/announcement] Reviewers project

2015-10-12 Thread Ciaran McCreesh
On Mon, 12 Oct 2015 13:13:15 +0800
Ian Delaney<idel...@gentoo.org> wrote:
> The main target learners here are keen users.  You can take told a
> mistake with the background and status of a dev. They don't. They are
> often intimidated and fearful if gentoo devs. We wonder why.

So how about letting them that if they make a mistake, there are now
ways of rectifying that quickly?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


  1   2   3   4   5   6   7   8   9   10   >