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

[Duncan]

William L. Thomson Jr. posted on Mon, 17 Oct 2016 01:36:33 -0400 as
excerpted:

> On Monday, October 17, 2016 4:37:50 AM EDT Duncan wrote:
>> William L. Thomson Jr. posted on Sun, 16 Oct 2016 18:30:44 -0400 as
>> 
>> excerpted:
>> > Then how would you test that against non official? You cannot install
>> > the same package twice at the same time with different USE flags. You
>> > can't even make binaries easily of the same package with different
>> > USE flags. The previous binary will get overwritten.
>> 
>> AFAIK, with current portage now you can have multiple binaries of the
>> same package, with different USE flags or built with different CFLAGS
>> or whatever, tho the feature's off by default.
> 
> Very nice, any chance that also includes generated binaries?
> 
> I make binaries for other systems to merge allot (binpkg). It sucks to
> have them clobbered with different USE flags. I always wanted to be able
> to keep the various binaries with different USE flags. Like some systems
> are hardened others not, so recompile gcc vs having 2.
> 
> Not sure if that is a step in that direction, but it is a cool feature
> just the same. Allows for further testing.

I was talking about binpkg (not actually installing, that is qmerging, 
multiple different versions of the package).  However, now that you asked 
the question, I can see that what I wrote was somewhat ambiguous.

Again, I've not followed this extremely closely as real life has been 
crowding out much of my gentooing recently (I bought a house and moved, 
was in a hotel temporarily for a few months in the mean time and am still 
rather bare-bones in the new place), but the general idea is pretty much 
exactly as you suggest.

With the appropriate option set, portage will bump a sequence number on 
the binpkg files when the same version is remerged instead of replacing 
the old binpkg.  There's infrastructure for tracking multiple binpkgs of 
the same version as well, and portage should be smart enough to match USE 
flags at least, selecting an existing binpkg that matches where possible, 
and building a new one to add to the collection when there's not an 
existing match.

I'm not likely to use it for that, but I've been going to look into the 
feature and see if it could help managing - live-vcs packages at some 
point... when I get the time.  The biggest problem with live-vcs packages 
ATM is the possibility of something breaking and not having a good record 
of your commit-build history, making bisecting more difficult than it 
should be.  This feature could conceivably help not only with that, but 
in allowing binpkg remerge of the last good build when something breaks, 
too, thus shortcutting the actual rebuild when there's not time to bisect 
and you just want to get a working package back again.

But that multi-binpkg should now be possible with current ~arch portage 
is about all I know, ATM, due to lack of time to do more than skim the 
proposed and ultimately approved commits as they're posted to the portage-
dev list (which I follow via gmane, as I do all my lists including this 
one).  I don't even know what to toggle to turn it on as I've not been 
following that closely.

But I imagine it could be awhile still until it's in stale for those that 
don't run ~arch...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 10:34:15 PM EDT Michał Górny wrote:
> On Mon, 17 Oct 2016 16:03:02 -0400
> 
> "William L. Thomson Jr."  wrote:
> > On Monday, October 17, 2016 7:34:57 PM EDT you wrote:
> > > On Mon, 17 Oct 2016 12:18:32 -0400
> > > 
> > > "William L. Thomson Jr."  wrote:
> > > > On Monday, October 17, 2016 6:08:41 PM EDT Michał Górny wrote:
> > > > > On Mon, 17 Oct 2016 11:48:53 -0400
> > > > > 
> > > > > Portage shows the repo it comes from because it is necessary for
> > > > > the package specification to be unique, i.e. two repositories can
> > > > > provide the same version of the same package.
> > > > 
> > > > It does not have to show it for that function. Showing the repo is a
> > > > visual
> > > > thing for the user during merge output. Portage does not have to have
> > > > ANY
> > > > output to do its job. Visual output is a user thing.
> > > 
> > > Excuse me but what is your goal here? I stated the rationale for that
> > > particular change. Your disagreement won't change why it was done.
> > 
> > What is your goal? Your assumption is wrong, this change is clearly visual
> > only...
> > 
> > Bug #510538: Include "::repository" in more messages.
> > https://github.com/gentoo/portage/commit/
> > 3f110090e50207d4ae3f6031ce6b1beafc80de46
> > 
> > Not technical purely visual...
> > https://bugs.gentoo.org/show_bug.cgi?id=510538
> 
> We could start with the fact that we're talking of two different
> changes. I was talking of the *original* change that started
> introducing repository name in various parts of output. You're talking
> about a followup commit.

It is not my fault your are talking about something else. I know the point I 
was making, visua. Thus the -bin suffix, visual. You said PMS, and now trying 
to 
connect the dots.

> Now, let me explain this to you.

Why do you feel it is your place to go around explaining things to people? 
Surely when you miss the point, and are talking about something different.

> The goal for ::repository output is to
> provide minimal package identifiers that can be used to 100% uniquely
> identify packages. As in, you see 'emerge -pv' output, you copy-paste
> the package from it and you get a guarantee that emerge will select
> the same package from the same repository.

If I find the original commit, it will say what you are? Outputting the repo on 
merge  so you can copy and paste is the only rational to that visual change.  
How do you copy and paste on a server without means for such? That would be an 
interesting justification for such change.

> Yes, it's purely visual. However, this visual change was motivated by
> an intent to provide functionally useful output.

No its a PMS requirement as you said not visual as I was saying...

> As a side note, Portage for some time did limit ::repository output to
> non-Gentoo repositories only. This was changed later in order to reduce
> the use of 'main repository' and make Portage less tied to the old
> Gentoo layout.

Thank your for that explanation. I had no idea what the change was for after 
reading the bug and commit.

Having done both I am not sure even your explanation is correct...

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[Michał Górny]

On Mon, 17 Oct 2016 16:03:02 -0400
"William L. Thomson Jr."  wrote:

> On Monday, October 17, 2016 7:34:57 PM EDT you wrote:
> > On Mon, 17 Oct 2016 12:18:32 -0400
> > 
> > "William L. Thomson Jr."  wrote:  
> > > On Monday, October 17, 2016 6:08:41 PM EDT Michał Górny wrote:  
> > > > On Mon, 17 Oct 2016 11:48:53 -0400
> > > >
> > > > Portage shows the repo it comes from because it is necessary for
> > > > the package specification to be unique, i.e. two repositories can
> > > > provide the same version of the same package.  
> > > 
> > > It does not have to show it for that function. Showing the repo is a
> > > visual
> > > thing for the user during merge output. Portage does not have to have ANY
> > > output to do its job. Visual output is a user thing.  
> > 
> > Excuse me but what is your goal here? I stated the rationale for that
> > particular change. Your disagreement won't change why it was done.  
> 
> What is your goal? Your assumption is wrong, this change is clearly visual 
> only...
> 
> Bug #510538: Include "::repository" in more messages.
> https://github.com/gentoo/portage/commit/
> 3f110090e50207d4ae3f6031ce6b1beafc80de46
> 
> Not technical purely visual...
> https://bugs.gentoo.org/show_bug.cgi?id=510538

We could start with the fact that we're talking of two different
changes. I was talking of the *original* change that started
introducing repository name in various parts of output. You're talking
about a followup commit.

Now, let me explain this to you. The goal for ::repository output is to
provide minimal package identifiers that can be used to 100% uniquely
identify packages. As in, you see 'emerge -pv' output, you copy-paste
the package from it and you get a guarantee that emerge will select
the same package from the same repository.

Yes, it's purely visual. However, this visual change was motivated by
an intent to provide functionally useful output.

As a side note, Portage for some time did limit ::repository output to
non-Gentoo repositories only. This was changed later in order to reduce
the use of 'main repository' and make Portage less tied to the old
Gentoo layout.

-- 
Best regards,
Michał Górny



pgpXdkPDpUnCb.pgp
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 7:34:57 PM EDT you wrote:
> On Mon, 17 Oct 2016 12:18:32 -0400
> 
> "William L. Thomson Jr."  wrote:
> > On Monday, October 17, 2016 6:08:41 PM EDT Michał Górny wrote:
> > > On Mon, 17 Oct 2016 11:48:53 -0400
> > >
> > > Portage shows the repo it comes from because it is necessary for
> > > the package specification to be unique, i.e. two repositories can
> > > provide the same version of the same package.
> > 
> > It does not have to show it for that function. Showing the repo is a
> > visual
> > thing for the user during merge output. Portage does not have to have ANY
> > output to do its job. Visual output is a user thing.
> 
> Excuse me but what is your goal here? I stated the rationale for that
> particular change. Your disagreement won't change why it was done.

What is your goal? Your assumption is wrong, this change is clearly visual 
only...

Bug #510538: Include "::repository" in more messages.
https://github.com/gentoo/portage/commit/
3f110090e50207d4ae3f6031ce6b1beafc80de46

Not technical purely visual...
https://bugs.gentoo.org/show_bug.cgi?id=510538

> I know that some Gentoo developers find that very hard to comprehend
> but in most of the cases, the people directly involved in it happen to
> know the rationale. Rationale is *why X did Y*, not *why I think that X
> did Y, as long as it contradicts what X says*.

I know your making an insulting comment...

But it is funny that you are calling out something you just did. You said why 
you thought a change was made not the facts. Now you see the commit, the 
comment, and the bug that caused the change.

Still want to use your PMS argument for pure visual things on package merge?

Try again, this time respectfully and politely...

-- 
William L. Thomson Jr.

signature.asc
Description: This is a digitally signed message part.

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

[Brian Evans]

On 10/14/2016 1:36 PM, Mike Gilbert wrote:
> On Fri, Oct 14, 2016 at 1:05 PM, William L. Thomson Jr.
>  wrote:
>> Problem
>> 1. There does not seem to be any file name requirement for binary packages.
>> 2. There are binary packages that end in -bin, which is good. However it is
>> not clear if that is an upstream 3rd party binary. Or a binary made by
>> compiling a large Gentoo package, by a Gentoo dev or contributor on a Gentoo
>> system. Like icedtea-bin for example, and likely some others.
>>
>> Suggested Solution
>> 1. Require 3rd party binary package names be suffixed with -bin. Many are
>> already named that thus require no change. A few package missing such may 
>> need
>> to be renamed to such.
>> 2. Require Gentoo made binaries have some other preffix, maybe -gbin. To
>> represent not only is it a bin, but it is a Gentoo self made binary. Much 
>> less
>> of these but would require some package renames.
>>
>> It is some what a moot problem, but I think it would be good to adopt such or
>> similar requirement, maybe in the PMS.
> 
> I see no reason to specify a file naming convention like this in PMS.
> This isn't really a technical problem, but rather a Gentoo policy
> issue. Other repos/distros should be free to call their ebuilds
> whatever they like.
> 
> Also, I don't think a file naming convention is the best way to
> implement this. I would suggest introducing a new piece of metadata:
> either an element in metadata.xml, or a global variable in ebuilds.
> 

+1 for metadata.xml

For anyone who cares, it is easily parsed.

Brian

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

[Michał Górny]

On Mon, 17 Oct 2016 12:18:32 -0400
"William L. Thomson Jr."  wrote:

> On Monday, October 17, 2016 6:08:41 PM EDT Michał Górny wrote:
> > On Mon, 17 Oct 2016 11:48:53 -0400
> > 
> > "William L. Thomson Jr."  wrote:  
> > > On Tuesday, October 18, 2016 4:18:51 AM EDT Kent Fredric wrote:  
> > > > There's a lot of "but what if you care!??!" things, perhaps this may be
> > > > an important one to you, but some people care a lot about LICENSE and
> > > > some people just don't.  
> > > 
> > > Yes, and some care about what repo it comes from. Which is why portage now
> > > shows you what repo it comes from as part of merge output. This is really
> > > no different.  
> > 
> > No.
> > 
> > Portage shows the repo it comes from because it is necessary for
> > the package specification to be unique, i.e. two repositories can
> > provide the same version of the same package.  
> 
> It does not have to show it for that function. Showing the repo is a visual 
> thing for the user during merge output. Portage does not have to have ANY 
> output to do its job. Visual output is a user thing.

Excuse me but what is your goal here? I stated the rationale for that
particular change. Your disagreement won't change why it was done.

I know that some Gentoo developers find that very hard to comprehend
but in most of the cases, the people directly involved in it happen to
know the rationale. Rationale is *why X did Y*, not *why I think that X
did Y, as long as it contradicts what X says*.

-- 
Best regards,
Michał Górny



pgp7EfMmj2lOZ.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

On Mon, 17 Oct 2016 13:09:52 -0400
Michael Mol  wrote:

> does that even make sense when the blob or helper utility is only used by 
> that package?

Makes it more useful in vetting and deploying security concerns.


pgpWmx3Rs8P_O.pgp
Description: OpenPGP digital signature

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

[Michael Mol]

On Monday, October 17, 2016 03:37:28 AM William L. Thomson Jr. wrote:
> On Monday, October 17, 2016 8:57:30 AM EDT Michał Górny wrote:
> > On Sun, 16 Oct 2016 18:30:44 -0400
> > 
> > "William L. Thomson Jr."  wrote:
> > > Part of the idea is to help differentiate the types of binaries in tree
> > > to
> > > hopefully get less binaries that are from source.
> > > 
> > > To start I just wanted to see about a policy for -bin, the other stuff
> > > was
> > > just extra after -bin itself was a policy. Unless it made sense to
> > > develop
> > > it in full,
> > > 
> > > -bin - Closed source binary ebuild
> > > -ebin - Self made binary from source
> > > -sbin - Binary ebuild of an open source package
> > 
> > Let's also add -c for C programs, and -cxx for C++ programs. -py for
> > pure Python stuff, -cpy when stuff includes extensions compiled in C,
> > -cxxpy extensions in C++. We should also have special -x86asm suffix
> > for packages that rely on non-portable x86 assembly, or maybe even
> > -x86asm-sse when they use some fancy instruction sets. And then don't
> > forget to add a suffix for license, for GUI library (because obviously
> > nobody wants GTK+ software on KDE systems, nor GTK+3 software on GTK+
> > systems).
> 
> Clearly being sarcastic as a binary is a binary. It doesn't matter what
> language, toolkit etc.

And what about when a package is mixed? When it has a closed firmware blob, or 
a statically-linked helper utility? Often, you'll see that stuff get unbundled, 
but does that even make sense when the blob or helper utility is only used by 
that package?

-- 
:wq

signature.asc
Description: This is a digitally signed message part.

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

[NP-Hardass]

On 10/17/2016 11:09 AM, Michał Górny wrote:
> On Mon, 17 Oct 2016 14:20:19 +0200
> Ulrich Mueller  wrote:
> 
>>> On Mon, 17 Oct 2016, M J Everitt wrote:  
>>
>>> On 17/10/16 08:41, William L. Thomson Jr. wrote:  
 To be clear I would suggest at MOST 3, -bin, -ebin, and -sbin.
 NO more.  
>>
>>> I don't see what problem you are trying to solve. Gentoo is a
>>> source-based distro .. any binaries are a last-resort or most
>>> certainly should be. Having a policy may be useful, but I see no
>>> proposition on this thread yet?  
>>
>> How about the following? I believe it is more or less the current
>> practice:
>>
>> "Gentoo usually builds its packages from source. Exceptionally,
>> a binary package can be provided instead (e.g., if upstream doesn't
>> provide a source) or in addition. Such packages should still follow
>> normal naming conventions and don't need any special suffix.
> 
> I think this contradicts the next paragraph. The 'or in addition' is
> followed by a statement that it doesn't need any special suffix.
> 
>> If a binary package is provided in addition to its source-based
>> equivalent, the name of the former should be suffixed with '-bin'
>> for distinction."
> 
> I think this could collide with Chrome vs Chromium. One could call
> Chromium a 'source-based equivalent' of Chrome, and therefore require
> the '-bin' suffix even though the names do not collide.
> 
> That said, I think I've seen a package somewhere using USE flags to
> switch between source and binary version. Such a policy would require
> it to change (and I approve that).
> 
I think Chrome/Chromium is a special case as upstream calls their binary
and source based releases by different names.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 6:08:41 PM EDT Michał Górny wrote:
> On Mon, 17 Oct 2016 11:48:53 -0400
> 
> "William L. Thomson Jr."  wrote:
> > On Tuesday, October 18, 2016 4:18:51 AM EDT Kent Fredric wrote:
> > > There's a lot of "but what if you care!??!" things, perhaps this may be
> > > an important one to you, but some people care a lot about LICENSE and
> > > some people just don't.
> > 
> > Yes, and some care about what repo it comes from. Which is why portage now
> > shows you what repo it comes from as part of merge output. This is really
> > no different.
> 
> No.
> 
> Portage shows the repo it comes from because it is necessary for
> the package specification to be unique, i.e. two repositories can
> provide the same version of the same package.

It does not have to show it for that function. Showing the repo is a visual 
thing for the user during merge output. Portage does not have to have ANY 
output to do its job. Visual output is a user thing.

Even if it needed and used internally, someone choose to change the outputted 
format as it did not contain the repo name in past merging. It may have been 
easier to just pass it along as it exists in code, but not sure if the format 
is exactly the same in code.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[Michael Orlitzky]

On 10/17/2016 01:43 AM, Ian Stakenvicius wrote:
> 
> There is also no particular policy that I am aware of for ensuring
> packages are designed to be built from source first and foremost.

If all you're looking for is something to cite, then binary packages run
afoul of most of our existing QA and security guidelines:

  * There are no USE flags to govern optional dependencies.

  * CFLAGS, LDFLAGS, etc. are not respected.

  * Certain compiler features (for example, stack-smashing protection)
are sidestepped.

  * Dependencies are bundled or statically linked.

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

[Ulrich Mueller]

> On Mon, 17 Oct 2016, Michał Górny wrote:

> On Mon, 17 Oct 2016 14:20:19 +0200
> Ulrich Mueller  wrote:

>> "Gentoo usually builds its packages from source. Exceptionally,
>> a binary package can be provided instead (e.g., if upstream doesn't
>> provide a source) or in addition. Such packages should still follow
>> normal naming conventions and don't need any special suffix.

> I think this contradicts the next paragraph. The 'or in addition' is
> followed by a statement that it doesn't need any special suffix.

Good catch. Strike "or in addition" from the second sentence.

>> If a binary package is provided in addition to its source-based
>> equivalent, the name of the former should be suffixed with '-bin'
>> for distinction."

> I think this could collide with Chrome vs Chromium. One could call
> Chromium a 'source-based equivalent' of Chrome, and therefore require
> the '-bin' suffix even though the names do not collide.

Hm, s/for distinction/if necessary for distinction/ ?

Ulrich


pgpA6iOpEtZf1.pgp
Description: PGP signature

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

[Michał Górny]

On Mon, 17 Oct 2016 11:48:53 -0400
"William L. Thomson Jr."  wrote:

> On Tuesday, October 18, 2016 4:18:51 AM EDT Kent Fredric wrote:
> > There's a lot of "but what if you care!??!" things, perhaps this may be
> > an important one to you, but some people care a lot about LICENSE and
> > some people just don't.  
> 
> Yes, and some care about what repo it comes from. Which is why portage now 
> shows you what repo it comes from as part of merge output. This is really no 
> different.

No.

Portage shows the repo it comes from because it is necessary for
the package specification to be unique, i.e. two repositories can
provide the same version of the same package.

-- 
Best regards,
Michał Górny



pgpLfqzshQeH4.pgp
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Tuesday, October 18, 2016 4:18:51 AM EDT Kent Fredric wrote:
> On Mon, 17 Oct 2016 09:32:30 -0400
> 
> "William L. Thomson Jr."  wrote:
> > > You know you can make that argument about *every* useflag right? Being
> > > unable to test with one and the other co-installed?
> > 
> > Did you see the comment where portage has this function now?
> 
> I don't actually know what he's referring to specifically, so I
> couldn't say. My best guess is something to do with "--prefix" but not
> sure.

Don't guess or assume, both are bad.
https://archives.gentoo.org/gentoo-dev/message/
4c8ab9209699e278876dfa9f11c8f1c6

> > > What are the benefits.
> > 
> > Knowing what you are getting in seconds, made by whom.
> 
> Would you similarly want the name of the last gentoo developer who
> touched the ebuild in the atom? No? Why not?

That is irrelevant, is it from Upstream or Gentoo, it is a binary choice.

> > > If Upstream and Gentoo both provide binary releases, but the Gentoo
> > > one sucks, we should just abolish the Gentoo one.
> > > 
> > > If Upstream and Gentoo both provide binary releases, but upstreams
> > > sucks, then we should not ship the upstream version.
> > 
> > What if you simply just do not know who made the binary?
> 
> Then the realisation that "not everyone cares" happens, and you go "ok,
> I care, so I have to spend effort to care".

Or you make improper assumptions. I bet many merged firefox-bin, just not 
wanting to merge from source to save time. Assuming they were getting the 
same, not realizing they were getting an Official binary from upstream not one 
built from a Gentoo firefox package.

> Or we're going to find ourselves back debating the old "Eapi in ebuild
> filename" debate, except worse, we'd be wanting EAPI visible in the
> ATOM!

This is not a as wide scoped a EAPI, and effects a very small percentage of 
ebuilds in tree.

> There's a lot of "but what if you care!??!" things, perhaps this may be
> an important one to you, but some people care a lot about LICENSE and
> some people just don't.

Yes, and some care about what repo it comes from. Which is why portage now 
shows you what repo it comes from as part of merge output. This is really no 
different.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 11:01:40 AM EDT Ian Stakenvicius wrote:
> On 17/10/16 10:54 AM, Michael Mol wrote:
> > There's also firefox-bin, which gets built upstream with profile-guided
> > optimizations enabled. PGO is unsupported outside of upstream's build
> > process, last I checked...but that was a few years ago.
> 
> Mozilla project has a dev that's supporting PGO builds in the source
> package now.
> 
> That said, the primary reason why the mozilla *-bin packages exist in
> Gentoo is because that's all that upstream officially supports.

There you go, I had NO idea that was an upstream binary. I thought it was the 
same as firefox from source. I assumed a Gentoo developer built and packaged 
that. I did not assume it was an official binary.

The only way for users to know is to investigate...

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[Kent Fredric]

On Mon, 17 Oct 2016 09:32:30 -0400
"William L. Thomson Jr."  wrote:

> > You know you can make that argument about *every* useflag right? Being
> > unable to test with one and the other co-installed?  
> 
> Did you see the comment where portage has this function now?

I don't actually know what he's referring to specifically, so I
couldn't say. My best guess is something to do with "--prefix" but not
sure.

It could just be plain ol' slotting and eselect, but that's not "for
everything".

> > What are the benefits.  
> 
> Knowing what you are getting in seconds, made by whom.

Would you similarly want the name of the last gentoo developer who
touched the ebuild in the atom? No? Why not?

> > If Upstream and Gentoo both provide binary releases, but the Gentoo
> > one sucks, we should just abolish the Gentoo one.
> > 
> > If Upstream and Gentoo both provide binary releases, but upstreams
> > sucks, then we should not ship the upstream version.  
> 
> What if you simply just do not know who made the binary?

Then the realisation that "not everyone cares" happens, and you go "ok,
I care, so I have to spend effort to care".

And then automatic masking strategies or emerge output decoration come
into play as viable solutions. As does showing the data in `eix`
output, etc.

Or we're going to find ourselves back debating the old "Eapi in ebuild
filename" debate, except worse, we'd be wanting EAPI visible in the
ATOM! 

There's a lot of "but what if you care!??!" things, perhaps this may be
an important one to you, but some people care a lot about LICENSE and
some people just don't.

And its *really* not worth stashing that metadata in the name for a
minority, who *can* answer their questions.

Granted, it is just *4* characters, we're debating about here, so the
bikeshed is rainbow striped with sparkles.

The trick with bikesheds is everyone wants to be the person who decides
the colour of the shed, but are too cautious to wage in on what colour
we paint the house.

Because if we paint the house, "ew, we're stuck with this" if it turns
out gross.

But if we paint the bikeshed nasty, "eh, its just a bike shed".


pgpmdCL_oON5J.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

On Mon, 17 Oct 2016 09:39:25 -0400
"William L. Thomson Jr."  wrote:
> 
> > PROPERTIES="binary:upstream"
> > 
> > or
> > 
> > PROPERTIES="binary:gentoo"
> > 
> > Assuming the right tooling, this allows a way to "canonically" define
> > what the type of binary is, and allow people to make whatever choices,
> > including automated rules.  
> 
> That is one way to go, but one would have to spend time to find out the 
> source.

Here is where it would be nice to have a printf style format argument for 
portage
where we can customize output listing.

Then you could just do like you'd do with git and add custom user defined spice.

Or like, as I mentioned other places, you could indicate to portage to restrict
options by default based on this property.

> > After you do that, you can deem a *convention* of adding -bin suffixes,
> > but instead of making it a "rule", make it simply a pattern that people
> > can follow if their package indicates they need suffixing.  
> 
> Patterns rather than rules/policies lead to inconsistent practice which is 
> the 
> case now.
> 
> > This means:
> > 
> > 1. "bin" packages don't need "-bin" suffixes, because metadata will convey
> > it 2. ... however, you can still use a "-bin" suffix and its encouraged.  
> 
> That doesn't really make sense with 1, saying you do not need -bin suffix but 
> then it is encouraged?

Because it really just doesn't make sense for some packages to be -bin,
some things will never exist in source form. Opera, Skype, there's no
need to state them as -bin, there will be nothing else for the
forseeable future.

Encouraging the use of -bin says <>

And there's no benefit to anyone to go pkg-move them all to have "-bin"
on the end. They've already got it installed. Its just noise without an
actual technical need.

> Which leads to more inconsistency in tree. The idea is to have it consistent 
> per policy and not leaving naming up to a maintainer.

Inconsistency is only "bad" if the reality underneath is itself,
consistent.

Forcing arbitrary consistency where the reality underneath is fluid
doesn't really do anything for us.

But the "need" to have "-bin" suffixing is really a case-by-case basis thing,
not a global axiom.

If you're *going* to differentiate, "-bin" is the recommended standard
way to differentiate, and you should use no other suffix for
differentiation.

But if there's no need for differentiation, don't differentiate for the
sake of doing so.

( and this "if there's a need to differentiate" covers all your
suggested cases with variants and testing, because those are
theoretical "needs", but not all packages need these things, and the
tree would be anarchy if we applied that logic to every package ...
every version of every package would be slotted "just in case!" )

> 
> Do you have any ideas how to reduce that and get others to help package 
> things 
> that other stick in tree as binary rather than from source?
> 

The growth of bins in tree are not something you can fix with policy.

All policy will do is make their presence more well known at best ( and
this can be achieved anyway without needing -bin suffixes on everything
)

The "Actual Problems" will still require people to do the work, for
proprietary software to die, and for upstream to stop packaging their
software like everyone is downloading it from source forge and running
it from their windows desktop.

Given all that . I don't see bin's evaporating any time soon.

Not at least without a "no bins at any cost" policy, which would only
harm our users.


pgpb3cdjgmcJY.pgp
Description: OpenPGP digital signature

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

[Michał Górny]

On Mon, 17 Oct 2016 14:20:19 +0200
Ulrich Mueller  wrote:

> > On Mon, 17 Oct 2016, M J Everitt wrote:  
> 
> > On 17/10/16 08:41, William L. Thomson Jr. wrote:  
> >> To be clear I would suggest at MOST 3, -bin, -ebin, and -sbin.
> >> NO more.  
> 
> > I don't see what problem you are trying to solve. Gentoo is a
> > source-based distro .. any binaries are a last-resort or most
> > certainly should be. Having a policy may be useful, but I see no
> > proposition on this thread yet?  
> 
> How about the following? I believe it is more or less the current
> practice:
> 
> "Gentoo usually builds its packages from source. Exceptionally,
> a binary package can be provided instead (e.g., if upstream doesn't
> provide a source) or in addition. Such packages should still follow
> normal naming conventions and don't need any special suffix.

I think this contradicts the next paragraph. The 'or in addition' is
followed by a statement that it doesn't need any special suffix.

> If a binary package is provided in addition to its source-based
> equivalent, the name of the former should be suffixed with '-bin'
> for distinction."

I think this could collide with Chrome vs Chromium. One could call
Chromium a 'source-based equivalent' of Chrome, and therefore require
the '-bin' suffix even though the names do not collide.

That said, I think I've seen a package somewhere using USE flags to
switch between source and binary version. Such a policy would require
it to change (and I approve that).

-- 
Best regards,
Michał Górny



pgpxaN1O4yIaW.pgp
Description: OpenPGP digital signature

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

[Ian Stakenvicius]

On 17/10/16 10:54 AM, Michael Mol wrote:
> 
> There's also firefox-bin, which gets built upstream with profile-guided 
> optimizations enabled. PGO is unsupported outside of upstream's build 
> process, 
> last I checked...but that was a few years ago.
> 

Mozilla project has a dev that's supporting PGO builds in the source
package now.

That said, the primary reason why the mozilla *-bin packages exist in
Gentoo is because that's all that upstream officially supports.




signature.asc
Description: OpenPGP digital signature

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

[Mike Gilbert]

On Mon, Oct 17, 2016 at 8:20 AM, Ulrich Mueller  wrote:
>> On Mon, 17 Oct 2016, M J Everitt wrote:
>
>> On 17/10/16 08:41, William L. Thomson Jr. wrote:
>>> To be clear I would suggest at MOST 3, -bin, -ebin, and -sbin.
>>> NO more.
>
>> I don't see what problem you are trying to solve. Gentoo is a
>> source-based distro .. any binaries are a last-resort or most
>> certainly should be. Having a policy may be useful, but I see no
>> proposition on this thread yet?
>
> How about the following? I believe it is more or less the current
> practice:
>
> "Gentoo usually builds its packages from source. Exceptionally,
> a binary package can be provided instead (e.g., if upstream doesn't
> provide a source) or in addition. Such packages should still follow
> normal naming conventions and don't need any special suffix.
>
> If a binary package is provided in addition to its source-based
> equivalent, the name of the former should be suffixed with '-bin'
> for distinction."

+1 from me.

Using the package name to make the binary package unique with respect
to the source-based package makes sense to me. Using it as a more
general indication of whether something is being built from source
does not make very much sense to me.

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

[Michael Mol]

On Monday, October 17, 2016 03:52:52 PM Kristian Fiskerstrand wrote:
> On 10/17/2016 03:47 PM, M. J. Everitt wrote:
> > On 17/10/16 14:44, William L. Thomson Jr. wrote:
> >>> If a binary package is provided in addition to its source-based
> >>> equivalent, the name of the former should be suffixed with '-bin'
> >>> for distinction."
> >> 
> >> Essentially what I would like to see in policy yes. Though it does not
> >> address the problem of identifying packages that can be built from
> >> source, that get put in tree as binary, for what ever reason.
> > 
> > Perhaps you can compile a list of such packages, as I would imagine QA
> > would be interested as to how 'widespread' this problem really is?
> 
> Off the top of my head I'm only aware of libreoffice-bin myself (and
> then it is a clear alternative to libreoffice if wanting the source),
> providing this as a binary is a convenience to end-users not wanting to
> spend 50 minutes on the compile.

There's also firefox-bin, which gets built upstream with profile-guided 
optimizations enabled. PGO is unsupported outside of upstream's build process, 
last I checked...but that was a few years ago.

-- 
:wq

signature.asc
Description: This is a digitally signed message part.

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 3:13:32 PM EDT M. J. Everitt wrote:
> On 17/10/16 15:09, Kristian Fiskerstrand wrote:
> > On 10/17/2016 04:04 PM, William L. Thomson Jr. wrote:
> >> Even if we have a list, what next? There are reasons why they are not
> >> packaged from source, and that will not change. Good to be aware, but
> >> without any sort of plan or means to address. Not sure it will matter.
> > 
> > The list would be helpful for discussions in any case to know the scope,
> > instead of making mountains out of molehills

I do not think it will be helpful, but here are some. I can see about 
producing a complete list but it requires time. Knowing there are some and 
more are being added should be enough.

Again even knowing this does not address the problem of why?

The reasons for the packages may differ, and I do not claim to know details 
about each, as to the reason why -bin vs from source. For Java based ones I 
know why, lots of dependencies not packaged.

app-misc/rundeck-cli-bin
net-p2p/go-ipfs-bin
dev-util/artifactory-bin
dev-util/jenkins-bin
sci-misc/netlogo-bin
sci-libs/openfoam-bin
games-util/pogo-manager-bin
dev-python/pypy3-bin
dev-python/pypy-bin
app-admin/filebeat-bin
app-admin/logstash-bin
app-text/jabref-bin
app-backup/spideroak-bin ? 
dev-java/maven-bin (requires bootstrapping, need maven to build maven)

If packages like Hadoop, Zookeeper, Wildfly, and others were added, they would 
likely be -bin as well. Several of these are quite large complex packages.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 3:52:52 PM EDT Kristian Fiskerstrand wrote:
>
> Off the top of my head I'm only aware of libreoffice-bin myself (and
> then it is a clear alternative to libreoffice if wanting the source),
> providing this as a binary is a convenience to end-users not wanting to
> spend 50 minutes on the compile.

That seems to be the main use of -bin, and the reason for like icedtea-bin, 
and other firefox-bin, etc. I would not suggest get rid of those, though could 
be in a different place if it bothers others.

I have always used oo-bin, but did compile libreoffice. Never compiled oo it 
was 
way to big.  At a point have used firefox-bin, and icedtea-bin, when not 
wanting to merge those from source. Just being lazy and not wanting some of 
the dependencies.
 
> I'm wondering if it wouldn't make sense to provide this as a binary
> package in a binhost instead of a -bin though (thats what I use
> internally myself in any case).

I am not pushing for such, but BSD does have a binary ports tree I believe 
available separate from the from source. I make my own binaries for other 
systems, to speed up updates. But I do not really use a binhost.

Long ago there was some company that was doing a repo of precompiled Gentoo 
binaries. But it went away a very long time ago. I haven't seen anything 
attempt it since. Not sure the demand, but things like Arch do exist now.

As for packages in tree as bin that can be from source, I have already pointed 
one out, dev-util/jenkins-bin. There are others.

Even if we have a list, what next? There are reasons why they are not packaged 
from source, and that will not change. Good to be aware, but without any sort 
of plan or means to address. Not sure it will matter.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Local workarounds with no reported bugs

[William L. Thomson Jr.]

On Monday, October 17, 2016 9:23:09 AM EDT Michał Górny wrote:
>
> Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
> in the past. Instead of contacting me (which would result in helpful
> explanation how to do things properly), they abused bash to disable
> the check function implicitly in the ebuilds.

Should we call "bash protective services" to report the abuse? They and I have 
no tolerance for bash abusers, they should be dealt with swiftly...

Now to go abuse ksh...

> Nobody bothered to inform me of the issue there. Instead, I had to
> notice it looking at the udev ebuilds accidentally. Furthermore, in
> most of the ebuilds the workaround was no longer necessary but nobody
> bothered to check that.

How would they know to contact you? Is it documented as the work flow 
somewhere?

> So we have a problem that affects around a half of git-r3 packages
> (using quick grep, results inaccurate), however minor it is. Worse, it
> affects the policy of preferring https and causes some people to reject
> the policy silently. And nobody gives a damn to report it!

If you see a problem fix it. If you have something to contribute to further a 
package then make the change. That in my opinion is working as a team, 
collaboration.
 
Also report the issues/changes in the log, tends to make a better argument in 
the long run and a better learning process and environment.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[M. J. Everitt]

On 17/10/16 15:09, Kristian Fiskerstrand wrote:
> On 10/17/2016 04:04 PM, William L. Thomson Jr. wrote:
>> Even if we have a list, what next? There are reasons why they are not 
>> packaged 
>> from source, and that will not change. Good to be aware, but without any 
>> sort 
>> of plan or means to address. Not sure it will matter.
> The list would be helpful for discussions in any case to know the scope,
> instead of making mountains out of molehills
>
+1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Local workarounds with no reported bugs

[Ian Stakenvicius]

On 17/10/16 03:23 AM, Michał Górny wrote:
> Hello, everyone.
> 
> I'd like to point out a major problem in Gentoo: there's a fair number
> of developers who add various local workarounds to problems they meet
> and don't bother to report a bug. Worst than that, this applies not
> only for upstream problems but also to Gentoo eclass/ebuild-related
> issues.
> 
> 
> Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
> in the past. Instead of contacting me (which would result in helpful
> explanation how to do things properly), they abused bash to disable
> the check function implicitly in the ebuilds.
> 
> Nobody bothered to inform me of the issue there. Instead, I had to
> notice it looking at the udev ebuilds accidentally. Furthermore, in
> most of the ebuilds the workaround was no longer necessary but nobody
> bothered to check that.
> 
> 
> Example 2: Coacher had problem with git-r3 not trying fallback URIs
> when earlier URI was https and https wasn't supported in git. So he
> reordered URIs to have https last. With tiny explanation in some random
> commit message.
> 
> So we have a problem that affects around a half of git-r3 packages
> (using quick grep, results inaccurate), however minor it is. Worse, it
> affects the policy of preferring https and causes some people to reject
> the policy silently. And nobody gives a damn to report it!
> 
> 
> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
> 
> Your thoughts?
> 

To be clear, are you referring here to workarounds only regarding
gentoo related stuffs (use of eclasses, package manager (ie portage)
functionality, etc) or are you also referring to the various
workarounds we as maintainers need to do to say, the use of build
tools (cmake, etc) or upstream's codebase/build system itself, to
successfully package it as well?





signature.asc
Description: OpenPGP digital signature

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

[M. J. Everitt]

On 17/10/16 14:52, William L. Thomson Jr. wrote:
> On Monday, October 17, 2016 2:47:00 PM EDT M. J. Everitt wrote:
>> On 17/10/16 14:44, William L. Thomson Jr. wrote:
 If a binary package is provided in addition to its source-based
 equivalent, the name of the former should be suffixed with '-bin'
 for distinction."
>>> Essentially what I would like to see in policy yes. Though it does not
>>> address the problem of identifying packages that can be built from
>>> source, that get put in tree as binary, for what ever reason.
>> Perhaps you can compile a list of such packages, as I would imagine QA
>> would be interested as to how 'widespread' this problem really is?
> That is a good task, but might be seen as finger pointing or tattling. I am 
> already an outcast. I rather let others, at least there is some awareness 
> now. 
I think enough finger-pointing has been done already, and in the absence
of other interested parties, some action on the part of the concerned
would either galvanise the point or dismiss the issue as insignificant.
>
> Though not sure what QA can do in the absence of some official policy to 
> enforce, beyond making requests.
>
It would be QA's decision as to whether the problem was an issue as
presented, and warranted some policy being drawn up and enforced.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Local workarounds with no reported bugs

[Raymond Jennings]

My personal opinion:

If you have to work around it, its already a bug.

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

[Kristian Fiskerstrand]

On 10/17/2016 04:04 PM, William L. Thomson Jr. wrote:
> Even if we have a list, what next? There are reasons why they are not 
> packaged 
> from source, and that will not change. Good to be aware, but without any sort 
> of plan or means to address. Not sure it will matter.

The list would be helpful for discussions in any case to know the scope,
instead of making mountains out of molehills

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 9:52:24 AM EDT William L. Thomson Jr. wrote:
> On Monday, October 17, 2016 2:47:00 PM EDT M. J. Everitt wrote:
> > On 17/10/16 14:44, William L. Thomson Jr. wrote:
> > >> If a binary package is provided in addition to its source-based
> > >> equivalent, the name of the former should be suffixed with '-bin'
> > >> for distinction."
> > > 
> > > Essentially what I would like to see in policy yes. Though it does not
> > > address the problem of identifying packages that can be built from
> > > source, that get put in tree as binary, for what ever reason.
> > 
> > Perhaps you can compile a list of such packages, as I would imagine QA
> > would be interested as to how 'widespread' this problem really is?
> 
> That is a good task, but might be seen as finger pointing or tattling. I am
> already an outcast. I rather let others, at least there is some awareness
> now.
> 
> Though not sure what QA can do in the absence of some official policy to
> enforce, beyond making requests.

By the way, even if a list is produced of binary packages in tree that can be 
built from source. It likely is not addressing the real issue.

Why are the not built from source?

Because they are large, complex, and require many un-packaged dependencies. 
Not to mention most tend to be Java. Which the more Java is neglected, more 
dependencies not packaged. The more binaries will be put in tree because it is 
cyclical. Things to package the large complex source are not, so people just 
stick it in tree as a binary.

It is simply to much work to package from source. Though that argument could 
be said about any aspect of Gentoo. It really comes down to a lack of man 
power, so corners get cut.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[Kristian Fiskerstrand]

On 10/17/2016 03:47 PM, M. J. Everitt wrote:
> On 17/10/16 14:44, William L. Thomson Jr. wrote:
>>> If a binary package is provided in addition to its source-based
>>> equivalent, the name of the former should be suffixed with '-bin'
>>> for distinction."
>> Essentially what I would like to see in policy yes. Though it does not 
>> address 
>> the problem of identifying packages that can be built from source, that get 
>> put in tree as binary, for what ever reason.
>>
> Perhaps you can compile a list of such packages, as I would imagine QA
> would be interested as to how 'widespread' this problem really is?
> 

Off the top of my head I'm only aware of libreoffice-bin myself (and
then it is a clear alternative to libreoffice if wanting the source),
providing this as a binary is a convenience to end-users not wanting to
spend 50 minutes on the compile.

I'm wondering if it wouldn't make sense to provide this as a binary
package in a binhost instead of a -bin though (thats what I use
internally myself in any case).

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 2:47:00 PM EDT M. J. Everitt wrote:
> On 17/10/16 14:44, William L. Thomson Jr. wrote:
> >> If a binary package is provided in addition to its source-based
> >> equivalent, the name of the former should be suffixed with '-bin'
> >> for distinction."
> > 
> > Essentially what I would like to see in policy yes. Though it does not
> > address the problem of identifying packages that can be built from
> > source, that get put in tree as binary, for what ever reason.
> 
> Perhaps you can compile a list of such packages, as I would imagine QA
> would be interested as to how 'widespread' this problem really is?

That is a good task, but might be seen as finger pointing or tattling. I am 
already an outcast. I rather let others, at least there is some awareness now. 

Though not sure what QA can do in the absence of some official policy to 
enforce, beyond making requests.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[M. J. Everitt]

On 17/10/16 14:44, William L. Thomson Jr. wrote:
>> If a binary package is provided in addition to its source-based
>> equivalent, the name of the former should be suffixed with '-bin'
>> for distinction."
> Essentially what I would like to see in policy yes. Though it does not 
> address 
> the problem of identifying packages that can be built from source, that get 
> put in tree as binary, for what ever reason.
>
Perhaps you can compile a list of such packages, as I would imagine QA
would be interested as to how 'widespread' this problem really is?



signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 9:40:57 AM EDT Michał Górny wrote:
> On Mon, 17 Oct 2016 03:37:28 -0400
> 
> "William L. Thomson Jr."  wrote:
> > On Monday, October 17, 2016 8:57:30 AM EDT Michał Górny wrote:
> > > On Sun, 16 Oct 2016 18:30:44 -0400
> > > 
> > > "William L. Thomson Jr."  wrote:
> > > > Part of the idea is to help differentiate the types of binaries in
> > > > tree to
> > > > hopefully get less binaries that are from source.
> > > > 
> > > > To start I just wanted to see about a policy for -bin, the other stuff
> > > > was
> > > > just extra after -bin itself was a policy. Unless it made sense to
> > > > develop
> > > > it in full,
> > > > 
> > > > -bin - Closed source binary ebuild
> > > > -ebin - Self made binary from source
> > > > -sbin - Binary ebuild of an open source package
> > > 
> > > Let's also add -c for C programs, and -cxx for C++ programs. -py for
> > > pure Python stuff, -cpy when stuff includes extensions compiled in C,
> > > -cxxpy extensions in C++. We should also have special -x86asm suffix
> > > for packages that rely on non-portable x86 assembly, or maybe even
> > > -x86asm-sse when they use some fancy instruction sets. And then don't
> > > forget to add a suffix for license, for GUI library (because obviously
> > > nobody wants GTK+ software on KDE systems, nor GTK+3 software on GTK+
> > > systems).
> > 
> > Clearly being sarcastic as a binary is a binary. It doesn't matter what
> > language, toolkit etc.
> 
> It doesn't matter for you. It may matter for others. Much like having
> binary signaled in name may not matter to others. Which is why in-band
> signaling is a bad idea.

It is already in practice now with regard to -bin suffix. It is just not 
consistent or policy.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 2:20:19 PM EDT Ulrich Mueller wrote:
> > On Mon, 17 Oct 2016, M J Everitt wrote:
> > On 17/10/16 08:41, William L. Thomson Jr. wrote:
> >> To be clear I would suggest at MOST 3, -bin, -ebin, and -sbin.
> >> NO more.
> > 
> > I don't see what problem you are trying to solve. Gentoo is a
> > source-based distro .. any binaries are a last-resort or most
> > certainly should be. Having a policy may be useful, but I see no
> > proposition on this thread yet?
> 
> How about the following? I believe it is more or less the current
> practice:

I am open, seems some of the problem others are not even aware of, so likely 
other ways to go about things.

> "Gentoo usually builds its packages from source. Exceptionally,
> a binary package can be provided instead (e.g., if upstream doesn't
> provide a source) or in addition. Such packages should still follow
> normal naming conventions and don't need any special suffix.

That some what goes against how things are now, if I understand correctly. It 
is suggesting a binary package would not require -bin. I think it should 
across the board for consistency.

> If a binary package is provided in addition to its source-based
> equivalent, the name of the former should be suffixed with '-bin'
> for distinction."

Essentially what I would like to see in policy yes. Though it does not address 
the problem of identifying packages that can be built from source, that get 
put in tree as binary, for what ever reason.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Local workarounds with no reported bugs

[Ilya Tumaykin]

On Monday 17 October 2016 09:23:09 Michał Górny wrote:
> Hello, everyone.

Hello.

Coacher's here.


> Example 2: Coacher had problem with git-r3 not trying fallback URIs
> when earlier URI was https and https wasn't supported in git. So he
> reordered URIs to have https last. With tiny explanation in some random
> commit message.

Original user's request [1], my PR [2], commit in question [3], bug: [4].
I've addressed a user's issue and reported a bug to Gentoo bugzilla the 
following day.
I don't see a problem with my workflow.


> So we have a problem that affects around a half of git-r3 packages
> (using quick grep, results inaccurate), however minor it is. Worse, it
> affects the policy of preferring https and causes some people to reject
> the policy silently.

Please share a link to this policy as I was unable to find it neither here [5], 
nor here [6].


> And nobody gives a damn to report it!

You expect me to create bugs the very second I encounter smth resembling a 
problem
without doing at least some minimum research on the matter? I don't do this.
I made the commit around 1 AM localtime, went to sleep,
and at 9 AM localtime you already jumping to conclusions in g-dev ML.


> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
> 
> Your thoughts?

You are quite emotional because of a change that didn't make it to the tree yet
expecting other people to provide 24/7 level of support for some reason.
At least this is how I see things from here.

No official policy is required.


[1]: https://github.com/gentoo/gentoo/pull/2570
[2]: https://github.com/gentoo/gentoo/pull/2572
[3]: 
https://github.com/gentoo/gentoo/pull/2572/commits/37a4eb12691b27631f4f23fe60dc26aff5f4fe47
[4]: https://bugs.gentoo.org/show_bug.cgi?id=597356
[5]: 
https://wiki.gentoo.org/wiki/Project:GLEP#Implemented_GLEPs_.28Final_or_Active.29
[6]: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies

-- 
Best regards.
Ilya Tumaykin.

signature.asc
Description: This is a digitally signed message part.

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 9:46:12 PM EDT Kent Fredric wrote:
> On Mon, 17 Oct 2016 03:41:13 -0400
> 
> "William L. Thomson Jr."  wrote:
> > To be clear I would suggest at MOST 3, -bin, -ebin, and -sbin. NO more.
> 
> It would be far better to simply have a PROPERTIES field in ebuilds or
> somesuch:

A -bin package is coming in as a dependency. How you do you know where it came 
from?

> PROPERTIES="binary:upstream"
> 
> or
> 
> PROPERTIES="binary:gentoo"
> 
> Assuming the right tooling, this allows a way to "canonically" define
> what the type of binary is, and allow people to make whatever choices,
> including automated rules.

That is one way to go, but one would have to spend time to find out the source.

> After you do that, you can deem a *convention* of adding -bin suffixes,
> but instead of making it a "rule", make it simply a pattern that people
> can follow if their package indicates they need suffixing.

Patterns rather than rules/policies lead to inconsistent practice which is the 
case now.

> This means:
> 
> 1. "bin" packages don't need "-bin" suffixes, because metadata will convey
> it 2. ... however, you can still use a "-bin" suffix and its encouraged.

That doesn't really make sense with 1, saying you do not need -bin suffix but 
then it is encouraged?

> 3.
> packages that end with '-bin' suffixes, but *arent* binaries can be clearly
> identified as such via metdata. ( Imagine something like
> dev-util/recycle-bin  )

The main issue I see with metadata is time. If your updating a system or 
several, a new -bin shows up potentially. You will have to spend time to 
determine the type of bin.

It also does not provide any "notification" to others that hey, this can be 
packaged from source.

> 4. any additional finessing of names to indicate what is going on can
> be decided by the maintainers in question, on a "as necessary basis"

Which leads to more inconsistency in tree. The idea is to have it consistent 
per policy and not leaving naming up to a maintainer.

> This means instead of "require this pattern" which will eventually
> result in useless chaos as packages rename all over the place, it will
> also avoid "require this pattern" where its not needed. ( neither
> www-client/opera, www-client/opera-developer, or www-client/opera-beta
> are source based, they're all binaries, unpacked from .deb's for crying
> out loud )

Then they should all have the -bin suffix. Already showing deviation from that 
while other packages have it. Exactly the inconsistency a policy would 
address.

> And we don't want to embrace visibly the idea that "free for all
> binaries" by having too many -bin packages in tree.

Part of the idea is to prevent the growing -bins in tree

Do you have any ideas how to reduce that and get others to help package things 
that other stick in tree as binary rather than from source?

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 9:29:15 PM EDT Kent Fredric wrote:
> On Sun, 16 Oct 2016 18:30:44 -0400
> 
> "William L. Thomson Jr."  wrote:
> > You actually came up with one I was not considering at first but provides
> > a
> > direct technical benefit you cannot achieve with a USE flag.
> > 
> > > If anything, I'd imagine if that case arose, it would manifest itself
> > > more
> > > 
> > > as:
> > >icedtea-bin + USE=official
> > 
> > Then how would you test that against non official? You cannot install the
> > same package twice at the same time with different USE flags. You can't
> > even make binaries easily of the same package with different USE flags.
> > The previous binary will get overwritten.
> 
> You know you can make that argument about *every* useflag right? Being
> unable to test with one and the other co-installed?

Did you see the comment where portage has this function now?
 
> What are the benefits.

Knowing what you are getting in seconds, made by whom.

> If Upstream and Gentoo both provide binary releases, but the Gentoo one
> sucks, we should just abolish the Gentoo one.
> 
> If Upstream and Gentoo both provide binary releases, but upstreams
> sucks, then we should not ship the upstream version.

What if you simply just do not know who made the binary?

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Local workarounds with no reported bugs

[Rich Freeman]

On Mon, Oct 17, 2016 at 9:09 AM, Raymond Jennings  wrote:
>
> Changing the status quo may require some adjustment though, but I suppose we
> could start by openly documenting a bug if we find a workaround that does
> not already have a bug number associated with it.  I've seen several ebuilds
> where workarounds are applied, but the workaround also has a bug number in
> the comment.

The other side of this is being approachable so that people don't feel
like they're about to demonstrate their incompetence by filing a bug.
FOSS tends to be a meritocracy, and I think people sometimes work in
their own little corner because they're afraid of being shamed for not
"getting it."  In reality having mistakes exposed shouldn't be
unpleasant, and we should be able to use it to grow.

I can see how a new developer might be reluctant to suggest that some
very experienced developer has made a mistake in an eclass.  Of
course, that doesn't make this OK.  We should be speaking up when we
see mistakes, and we should be gracious both when our mistakes are
pointed out or somebody doing so has made a mistake themselves.

-- 
Rich

Re: [gentoo-dev] Local workarounds with no reported bugs

[Raymond Jennings]

My biggest ​opinion regarding workarounds and bugs, is that we're sweeping
things under the rug that should at least be documented, and perhaps
fixed...or even punted upstream if its serious enough.

Changing the status quo may require some adjustment though, but I suppose
we could start by openly documenting a bug if we find a workaround that
does not already have a bug number associated with it.  I've seen several
ebuilds where workarounds are applied, but the workaround also has a bug
number in the comment.

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

[Ulrich Mueller]

> On Mon, 17 Oct 2016, M J Everitt wrote:

> On 17/10/16 08:41, William L. Thomson Jr. wrote:
>> To be clear I would suggest at MOST 3, -bin, -ebin, and -sbin.
>> NO more.

> I don't see what problem you are trying to solve. Gentoo is a
> source-based distro .. any binaries are a last-resort or most
> certainly should be. Having a policy may be useful, but I see no
> proposition on this thread yet?

How about the following? I believe it is more or less the current
practice:

"Gentoo usually builds its packages from source. Exceptionally,
a binary package can be provided instead (e.g., if upstream doesn't
provide a source) or in addition. Such packages should still follow
normal naming conventions and don't need any special suffix.

If a binary package is provided in addition to its source-based
equivalent, the name of the former should be suffixed with '-bin'
for distinction."

Ulrich


pgp4HRGyLLjyu.pgp
Description: PGP signature

Re: [gentoo-dev] Local workarounds with no reported bugs

[Paweł Hajdan , Jr .]

On 17/10/2016 12:42, Patrice Clement wrote:
> We don't need yet another policy to "fix" two problems you've
> encountered

+1 ; policies don't always fix things

It's a worthwhile guideline though - as Gentoo devs, and maybe even
wider community, we should work together to fix problems.

That's one of the advantages I see in open source and communities - that
we don't need to work around each other's bugs, but can just squash them
at the source.

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] FOSDEM 2017

[Kristian Fiskerstrand]

Hi,

I'll take the coordiation role for FOSDEM 2017 again. I have already
submitted stand request to FOSDEM and hope we get accepted this year again.

If you want to contribute to the planning for this event please join
fosdem@g.o alias and #gentoo-fosdem on IRC.

Wiki page is set up at https://wiki.gentoo.org/wiki/FOSDEM_2017 (but
nearly without content yet)

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Local workarounds with no reported bugs

[Patrice Clement]

Monday 17 Oct 2016 09:23:09, Michał Górny wrote :
> Hello, everyone.
> 
> I'd like to point out a major problem in Gentoo: there's a fair number
> of developers who add various local workarounds to problems they meet
> and don't bother to report a bug. Worst than that, this applies not
> only for upstream problems but also to Gentoo eclass/ebuild-related
> issues.
>
> --8<--snip--8<--snip--8<--snip--8<--snip--8<--
>
> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
> 
> Your thoughts?
> 
> -- 
> Best regards,
> Michał Górny
> 

Michal

You're being emotional in my opinion and as a result, are painting *all* Gentoo
developers with a broad brush. Relax. We don't need yet another policy to "fix"
two problems you've encountered, this sounds silly. To be honest, I don't
understand your 2nd example: a change was made in an eclass and as all eclass
changes, these need to be discussed either here on the mailing list or via IRC.
You seem to be maintainer of git-r3; who made the commit? did you sign off
on it? if not, why was it merged? etc. Give us a bit more context please. Your
message looks more like a rant rather than a rational proposal.

Cheers,

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Local workarounds with no reported bugs

[Raymond Jennings]

On Mon, Oct 17, 2016 at 12:23 AM, Michał Górny  wrote:

> Hello, everyone.
>
> I'd like to point out a major problem in Gentoo: there's a fair number
> of developers who add various local workarounds to problems they meet
> and don't bother to report a bug. Worst than that, this applies not
> only for upstream problems but also to Gentoo eclass/ebuild-related
> issues.
>
>
> Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
> in the past. Instead of contacting me (which would result in helpful
> explanation how to do things properly), they abused bash to disable
> the check function implicitly in the ebuilds.
>
> Nobody bothered to inform me of the issue there. Instead, I had to
> notice it looking at the udev ebuilds accidentally. Furthermore, in
> most of the ebuilds the workaround was no longer necessary but nobody
> bothered to check that.
>
>
> Example 2: Coacher had problem with git-r3 not trying fallback URIs
> when earlier URI was https and https wasn't supported in git. So he
> reordered URIs to have https last. With tiny explanation in some random
> commit message.
>
> So we have a problem that affects around a half of git-r3 packages
> (using quick grep, results inaccurate), however minor it is. Worse, it
> affects the policy of preferring https and causes some people to reject
> the policy silently. And nobody gives a damn to report it!
>
>
> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
>
> Your thoughts?
>
> --
> Best regards,
> Michał Górny
> 
>

+1.

Anything serious enough to require a workaround or an upstream deviation
should be documented in a bug report.

And may also be something we should poke upstream about anyway. If junk
hits us in gentoo, it may have come from upstream and may affect users
outside of gentoo.

Re: [gentoo-dev] Local workarounds with no reported bugs

[Kent Fredric]

On Mon, 17 Oct 2016 09:23:09 +0200
Michał Górny  wrote:

> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
> 
> Your thoughts?

Obviously I assume this is still a "to taste" thing, because when
you're packaging something, and you find something upstream have done
which makes sense for them, but not for gentoo, you're inclined to go
"oh, right", and just side-step that, without such thought as to file a
bug in the process.

So obviously not *all* workarounds can have useful bugs filed for them.

Unless I'm supposed to see the bug before I ship the code, and file a
bug in gentoo, ship the ebuild with the workaround, and then close the
bug, even though the bug never existed from any users perspective.

So its just a matter of more clearly defining the scopes of workarounds
were talking about here.



pgpS51GnH9zAz.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

On Mon, 17 Oct 2016 03:41:13 -0400
"William L. Thomson Jr."  wrote:

> To be clear I would suggest at MOST 3, -bin, -ebin, and -sbin. NO more.

It would be far better to simply have a PROPERTIES field in ebuilds or somesuch:

PROPERTIES="binary:upstream"

or

PROPERTIES="binary:gentoo"

Assuming the right tooling, this allows a way to "canonically" define
what the type of binary is, and allow people to make whatever choices,
including automated rules.

After you do that, you can deem a *convention* of adding -bin suffixes,
but instead of making it a "rule", make it simply a pattern that people
can follow if their package indicates they need suffixing.

This means:

1. "bin" packages don't need "-bin" suffixes, because metadata will convey it
2. ... however, you can still use a "-bin" suffix and its encouraged.
3. packages that end with '-bin' suffixes, but *arent* binaries can be
clearly identified as such via metdata. ( Imagine something like
dev-util/recycle-bin  )
4. any additional finessing of names to indicate what is going on can
be decided by the maintainers in question, on a "as necessary basis"

This means instead of "require this pattern" which will eventually
result in useless chaos as packages rename all over the place, it will
also avoid "require this pattern" where its not needed. ( neither
www-client/opera, www-client/opera-developer, or www-client/opera-beta
are source based, they're all binaries, unpacked from .deb's for crying
out loud )

And we don't want to embrace visibly the idea that "free for all
binaries" by having too many -bin packages in tree.

We have to keep it balanced.


pgpEWWJIdl2ZB.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

On Sun, 16 Oct 2016 18:30:44 -0400
"William L. Thomson Jr."  wrote:

> You actually came up with one I was not considering at first but provides a 
> direct technical benefit you cannot achieve with a USE flag.
>  
> > If anything, I'd imagine if that case arose, it would manifest itself more
> > as:
> > 
> >icedtea-bin + USE=official  
> 
> Then how would you test that against non official? You cannot install the 
> same 
> package twice at the same time with different USE flags. You can't even make 
> binaries easily of the same package with different USE flags. The previous 
> binary will get overwritten.

You know you can make that argument about *every* useflag right? Being unable to
test with one and the other co-installed?

The thing is, for the majority of our useflags there is no *Need* to. 

And more importantly, simply separating the logic into different package names
does *not* automatically imply they can be installed side-by-side.

They may be mutually exclusive. And plenty of things make this a problem
that is intractable to solve.

> There you go, a case why it would make sense to have it be -bin and -ebin. 
> You can install both those at the same time and test.

Hence, my argument is not for "a possible use for it" in the "It could be handy
for developers to do this" sense.

The question is for our *users*: Who out there actually wants to do
this sort of thing.

What are the benefits.

If Upstream and Gentoo both provide binary releases, but the Gentoo one
sucks, we should just abolish the Gentoo one.

If Upstream and Gentoo both provide binary releases, but upstreams
sucks, then we should not ship the upstream version.


pgpRJ9wjiENzJ.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

On Sun, 16 Oct 2016 18:20:42 -0400
"William L. Thomson Jr."  wrote:

> Part of the idea everyone is missing is time... It takes time to go look at 
> information a package metadata.xml If the package is coming in as a 
> dependency. Instead of just being able to visually look at the package name 
> and know.
> 
> This is a binary package from upstream
> This is a binary package from Gentoo

There's quite a lot of metadata that *might* be important ( but isn't ) and is 
only
available as metadata, not visible in the package name itself.

Like, LICENSE, and "where its fetched from"

  dev-lang/perl-artistic-gpl2+-cpan-5.24.1 

This is just getting silly.

Exposing metadata in the package atom should be out of *necessity*,
not some misguided sense of visibility.

For every other kind of metadata, those who care about it should invest
effort into exposing it.

That's why my example elsewhere abuses the LICENSE field to demonstrate
how end users can make a choice/see the reality using out-of-name
metadata.

But there is quite frankly no *need* for -gbin and -bin

The only real /technical/ reason we have both -bin and -gbin is it
avoids the binary version competing for a name with the source-built
version.

That is, if there is a "-bin" package, its viable some day there may be
a non "-bin" package, and that they may both be available side-by-side
and you may wish to choose between them.

But "-gbin" and "-bin" coexisting side-by side is a usecase I can't see
being useful to anybody.



pgpCBAlsKLSRn.pgp
Description: OpenPGP digital signature

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

[M. J. Everitt]

On 17/10/16 08:41, William L. Thomson Jr. wrote:
> On Monday, October 17, 2016 9:17:48 AM EDT Ulrich Mueller wrote:
>> But seriously, what has become of the package tags proposal? It seems
>> to me that it would fit some of the things suggested previously in
>> this thread.
>> https://wiki.gentoo.org/wiki/User:Antarus/Package_Tags
> That is interesting, but I think is aiming to solve a different problemt. 
> Plus 
> it is not requiring any sort of policy that binary ebuilds end in -bin. Which 
> is the main idea. The rest was more icing.
>
> To be clear I would suggest at MOST 3, -bin, -ebin, and -sbin. NO more.
>
I don't see what problem you are trying to solve. Gentoo is a
source-based distro .. any binaries are a last-resort or most certainly
should be. Having a policy may be useful, but I see no proposition on
this thread yet?



signature.asc
Description: OpenPGP digital signature

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

[Michał Górny]

On Mon, 17 Oct 2016 03:37:28 -0400
"William L. Thomson Jr."  wrote:

> On Monday, October 17, 2016 8:57:30 AM EDT Michał Górny wrote:
> > On Sun, 16 Oct 2016 18:30:44 -0400
> > 
> > "William L. Thomson Jr."  wrote:  
> > > Part of the idea is to help differentiate the types of binaries in tree to
> > > hopefully get less binaries that are from source.
> > > 
> > > To start I just wanted to see about a policy for -bin, the other stuff was
> > > just extra after -bin itself was a policy. Unless it made sense to develop
> > > it in full,
> > > 
> > > -bin - Closed source binary ebuild
> > > -ebin - Self made binary from source
> > > -sbin - Binary ebuild of an open source package  
> > 
> > Let's also add -c for C programs, and -cxx for C++ programs. -py for
> > pure Python stuff, -cpy when stuff includes extensions compiled in C,
> > -cxxpy extensions in C++. We should also have special -x86asm suffix
> > for packages that rely on non-portable x86 assembly, or maybe even
> > -x86asm-sse when they use some fancy instruction sets. And then don't
> > forget to add a suffix for license, for GUI library (because obviously
> > nobody wants GTK+ software on KDE systems, nor GTK+3 software on GTK+
> > systems).  
> 
> Clearly being sarcastic as a binary is a binary. It doesn't matter what 
> language, toolkit etc.

It doesn't matter for you. It may matter for others. Much like having
binary signaled in name may not matter to others. Which is why in-band
signaling is a bad idea.

-- 
Best regards,
Michał Górny



pgpubOWUxC3CF.pgp
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 9:17:48 AM EDT Ulrich Mueller wrote:
>
> But seriously, what has become of the package tags proposal? It seems
> to me that it would fit some of the things suggested previously in
> this thread.
> https://wiki.gentoo.org/wiki/User:Antarus/Package_Tags

That is interesting, but I think is aiming to solve a different problemt. Plus 
it is not requiring any sort of policy that binary ebuilds end in -bin. Which 
is the main idea. The rest was more icing.

To be clear I would suggest at MOST 3, -bin, -ebin, and -sbin. NO more.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[William L. Thomson Jr.]

On Monday, October 17, 2016 8:57:30 AM EDT Michał Górny wrote:
> On Sun, 16 Oct 2016 18:30:44 -0400
> 
> "William L. Thomson Jr."  wrote:
> > Part of the idea is to help differentiate the types of binaries in tree to
> > hopefully get less binaries that are from source.
> > 
> > To start I just wanted to see about a policy for -bin, the other stuff was
> > just extra after -bin itself was a policy. Unless it made sense to develop
> > it in full,
> > 
> > -bin - Closed source binary ebuild
> > -ebin - Self made binary from source
> > -sbin - Binary ebuild of an open source package
> 
> Let's also add -c for C programs, and -cxx for C++ programs. -py for
> pure Python stuff, -cpy when stuff includes extensions compiled in C,
> -cxxpy extensions in C++. We should also have special -x86asm suffix
> for packages that rely on non-portable x86 assembly, or maybe even
> -x86asm-sse when they use some fancy instruction sets. And then don't
> forget to add a suffix for license, for GUI library (because obviously
> nobody wants GTK+ software on KDE systems, nor GTK+3 software on GTK+
> systems).

Clearly being sarcastic as a binary is a binary. It doesn't matter what 
language, toolkit etc.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[M. J. Everitt]

On 17/10/16 08:17, Ulrich Mueller wrote:
>
> But seriously, what has become of the package tags proposal? It seems
> to me that it would fit some of the things suggested previously in
> this thread.
> https://wiki.gentoo.org/wiki/User:Antarus/Package_Tags
>
> Ulrich
Looks rational to me .. blockers?



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Local workarounds with no reported bugs

[Michał Górny]

Hello, everyone.

I'd like to point out a major problem in Gentoo: there's a fair number
of developers who add various local workarounds to problems they meet
and don't bother to report a bug. Worst than that, this applies not
only for upstream problems but also to Gentoo eclass/ebuild-related
issues.


Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
in the past. Instead of contacting me (which would result in helpful
explanation how to do things properly), they abused bash to disable
the check function implicitly in the ebuilds.

Nobody bothered to inform me of the issue there. Instead, I had to
notice it looking at the udev ebuilds accidentally. Furthermore, in
most of the ebuilds the workaround was no longer necessary but nobody
bothered to check that.


Example 2: Coacher had problem with git-r3 not trying fallback URIs
when earlier URI was https and https wasn't supported in git. So he
reordered URIs to have https last. With tiny explanation in some random
commit message.

So we have a problem that affects around a half of git-r3 packages
(using quick grep, results inaccurate), however minor it is. Worse, it
affects the policy of preferring https and causes some people to reject
the policy silently. And nobody gives a damn to report it!


Therefore, I'd like to request establishing an official policy against
workarounds with no associated bug reports.

Your thoughts?

-- 
Best regards,
Michał Górny



pgpJLw7ED9eKm.pgp
Description: OpenPGP digital signature

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

[Ulrich Mueller]

> On Mon, 17 Oct 2016, Michał Górny wrote:

> Let's also add -c for C programs, and -cxx for C++ programs. -py for
> pure Python stuff, -cpy when stuff includes extensions compiled in
> C, -cxxpy extensions in C++. We should also have special -x86asm
> suffix for packages that rely on non-portable x86 assembly, or maybe
> even -x86asm-sse when they use some fancy instruction sets. And then
> don't forget to add a suffix for license,

Yes please, let's add a -non-free suffix to all packages with a
license outside of the @FREE group. ;)

> for GUI library (because obviously nobody wants GTK+ software on KDE
> systems, nor GTK+3 software on GTK+ systems).

But seriously, what has become of the package tags proposal? It seems
to me that it would fit some of the things suggested previously in
this thread.
https://wiki.gentoo.org/wiki/User:Antarus/Package_Tags

Ulrich


pgpdByYpS7G0Z.pgp
Description: PGP signature