On Thu, 9 Mar 2017 11:06:54 -0500
Michael Orlitzky wrote:
> 2. Work with the PMS team to come up with a solution for the
> problem.
I think dependency labels & parts fill nicely that void.
I have not done proper research about it but I have yet to see a
serious proposal for its inclusion tho
> On Thu, 09 Mar 2017, William L Thomson wrote:
> Along the lines of failures. What if a system has rm aliased to
> prompt before removal? In that case rm -r would fail, but rm -fr
> would not. That would cause failures for the user and not the
> developer. Assuming rm does not disable prompt
On Thursday, March 9, 2017 7:43:50 PM EST William L. Thomson Jr. wrote:
> On Thursday, March 9, 2017 7:08:12 PM EST Michael Orlitzky wrote:
> > Whether "-f" is appropriate or not depends on the context.
> >
> > With firebird, you expect all of those directories to exist, and you
> > want to be not
On Thursday, March 9, 2017 7:08:12 PM EST Michael Orlitzky wrote:
>
> Whether "-f" is appropriate or not depends on the context.
>
> With firebird, you expect all of those directories to exist, and you
> want to be notified (so that you can update the ebuild) if one of them
> isn't there. If upstr
On 03/09/2017 06:16 PM, William L. Thomson Jr. wrote:
>
> Case in point dev-db/firebird use to have a line like
>
> rm -rf "${S}"/extern/{btyacc,editline,icu} || die
>
> But if you look at current ebuild it is now
>
> rm -r "${S}"/extern/{btyacc,editline,icu} || die
>
> The force option/argume
On Thursday, March 9, 2017 2:28:47 PM EST Michael Orlitzky wrote:
> On 03/09/2017 02:00 PM, William L. Thomson Jr. wrote:
> > Under what circumstances?
> >
> > ...
> >
> > Seems like it is not possible to generate the above permission issue.
>
> I can make them up all day...
I cannot find the e
On 03/09/2017 02:00 PM, William L. Thomson Jr. wrote:
>
> Under what circumstances?
>
> ...
>
> Seems like it is not possible to generate the above permission issue.
>
I can make them up all day...
* VENDOR_PATH=VENDORPN="" and we try to "rm -rf /"
* A hard drive error occurs.
* Ba
On Thursday, March 9, 2017 1:29:55 PM EST Michael Orlitzky wrote:
> On 03/09/2017 01:21 PM, William L. Thomson Jr. wrote:
> > Pretty sure no need for the ||die, rm -fr should never fail.
> >
> > rm -fr "${VENDOR_PATH}/${VENDORPN}" || die
>
> $ rm -rf /bin/cp || echo "it failed"
> rm: cannot remov
On 03/09/2017 01:21 PM, William L. Thomson Jr. wrote:
> Pretty sure no need for the ||die, rm -fr should never fail.
>
> rm -fr "${VENDOR_PATH}/${VENDORPN}" || die
>
$ rm -rf /bin/cp || echo "it failed"
rm: cannot remove '/bin/cp': Permission denied
it failed
Pretty sure no need for the ||die, rm -fr should never fail.
rm -fr "${VENDOR_PATH}/${VENDORPN}" || die
--
William L. Thomson Jr.
signature.asc
Description: This is a digitally signed message part.
All,
things like this are already being done in the tree (by app-admin/consul
for example), and I'n sure by other go ebuilds as well.
I would like to add this functionality to golang-vcs-snapshot.eclass as
a way to remove duplicate code from ebuilds and make this available to
other ebuilds as wel
On 03/09/2017 10:36 AM, William Hubbs wrote:
> On Wed, Mar 08, 2017 at 07:49:08PM -0500, Michael Orlitzky wrote:
>> On 03/08/2017 02:20 PM, William Hubbs wrote:
>>>
>>> Another option is to not force this and rely on everyone to use
>>> --with-bdeps=y to make the rebuild happen.
>>>
>>
>> That feat
On 09/03/17 10:34 AM, Michał Górny wrote:
> The second group (patch sets) is more unclear. AFAICS some people argue
> that packages with major patch sets applied should be distinguished by
> separate package names. Others see that applying them via USE flags is
> easier.
>
> Separate packages are
On Thu, Mar 9, 2017 at 10:34 AM, Michał Górny wrote:
>
> 1. classic forks -- package B is forked out of A, and the development of
> both continue independently (eudev/systemd, ffmpeg/libav);
>
> 2. large patch sets / continuously rebased forks -- where the particular
> set of changes is usually ap
On Wed, Mar 08, 2017 at 07:49:08PM -0500, Michael Orlitzky wrote:
> On 03/08/2017 02:20 PM, William Hubbs wrote:
> >
> > Another option is to not force this and rely on everyone to use
> > --with-bdeps=y to make the rebuild happen.
> >
>
> That feature is portage-only. Slot operator deps in DEPE
Hi, everyone.
Here's a topic that came to me with relevance to the recent events. I
don't think we have some official guidelines how to handle the various
kinds of forks, to ensure that users know what they're getting. So I'd
like to start a discussion on the topic.
For a start, I'd like to class
16 matches
Mail list logo