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

[Daniel Campbell]

On 10/17/2016 01:21 AM, Kent Fredric wrote:
> 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.
> 
+1

It sounds like a good intention, but users who don't check that sort of
thing likely don't care or won't know which decision is "right" for
them. Metadata makes the most sense, as that's the entire point of
_meta_data. app-portage/gentoolkit is imo almost required for
administering a Gentoo machine. equery and eix are amazingly useful as a
user. I can't fathom a reason not to use them.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

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

[Ciaran McCreesh]

On Mon, 17 Oct 2016 16:43:40 -0400
"William L. Thomson Jr."  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] 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] 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] 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] 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] 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] 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] 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

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

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

[Michał Górny]

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).

-- 
Best regards,
Michał Górny



pgpVwsAeqGE5p.pgp
Description: OpenPGP digital signature

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

[Ian Stakenvicius]

On 16/10/16 10:43 PM, William L. Thomson Jr. wrote:
> On Sunday, October 16, 2016 9:19:25 PM EDT Ian Stakenvicius wrote:
>>
>> *IF* we were going to make use of upstream vs gentoo-generated binary
>> packages in the tree, they *WOULD* block one-another as they would
>> collide file-wise at least partially if not completely.  So there
>> wouldn't be any testing between the two variants on the same installed
>> system.
> 
> That was not an argument I was initially making as justification, but via 
> slotting and changing names of binaries and/or paths it could be done.
> 
> It is in part why systems like eselect exist to switch between 
> implementations. In Java's case there is a wrapper around all binaries that 
> is 
> called, which handles which ones is used. run-java-tool.bash. In addition to 
> things like java-cpnfig etc.
> 
> Also why there is gcc-config, binutils-config, etc. Part of the beauty of 
> Gentoo 
> is installing things that collide, and switching between them for testing.
> 
>>> Maybe the upstream binary runs better, does not crash, etc. Or the Gentoo
>>> one does. If the Gentoo one is better, it could be used to get a
>>> reluctant upstream to make changes. If worse could be used to help figure
>>> out where its going wrong.
>>
>> OK, so here's how things *actually work* in the gentoo repo:
> 
> Because I need such an explanation? I think it could be a little less harsh 
> no?
> 
>> #1, binary packages aren't made unless there's a really good reason
>> for them -- the primary one being that there isn't any other option
>> provided by upstream.
> 
> Is that a mandated policy? There are ebuilds in tree that are not that way.
> 
>> #2, if there is a binary package then the only reason why a gentoo dev
>> would roll it instead of using upstream's version is because the
>> upstream one fails hard or has too many bugs, security
>> vulnerabilities, whatever.  This is as much done on a per-version
>> basis within a package as it is on a per-package one.
> 
> There is a 3rd case, where the package is to complex to package from source. 
> Things like jenkins-bin, and there are others... jenkins can be packaged from 
> source, as some others can be. If they were -sbin, maybe more would be aware 
> and try to package from source vs use as binary because it is to hard to 
> package from source.
> 
>> All of this discussion is centered around trying to bring convention
>> to a problem that simply doesn't exist.  
> 
> Maybe you are just not aware. Which if the packages were required to be 
> named, 
> say -sbin a binary that is a from source package, just not packaged you would 
> be aware.
> 
> They exist, go look! Also seems to be growing.
> 
>> Also, if the idea here is to
>> open the door for a flood of gentoo-dev-rolled *-bin packages in the
>> gentoo repo for end-user convenience,
> 
> No that is not the case, and that is done in extreme limited case. I am not 
> pushing for more binary packages by any means. It would simply be to 
> differentiate, so anyone knows by file name what they are getting, from 
> upstream or from Gentoo.
> 
>> then we should similarly stop
>> this discussion right now too.  How about, instead, you could focus on
>> setting up two (additional) repos -- one containing gentoo-built
>> binary packages, another containing upstream-only packages.
> 
> That is not my goal. I am trying to bring to attention -bin packages in tree. 
> -sbin packages should draw attention to get people to package them from 
> source.
> 
>> That way
>> it'll be very obvious to end-users what they'll be using because
>> they'll know exactly based on where it comes from. 
> 
> This is an issue of things already in tree, and packages being added in tree, 
> in Gentoo's repo. Which I obviously cannot do so its not my work.
> 
>> It'll also be very
>> easy for end-users to control which one is used, just by choosing
>> which repo it comes from.  AND, it'll keep them from polluting the
>> main gentoo repo too.
> 
> It is already polluted, seems you are unaware, but now you know.
> 
> Likely wasn't intentional but came across VERY hostile, and completely 
> missing 
> the mark and point.
> 

It wasn't meant to be hostile but yes my patience was lacking and I
apologize.

I agree, there are a number of binary packages in the tree already and
fortunately most of them have a -bin in their name despite this not
being any formal requirement.  There is also no particular policy that
I am aware of for ensuring packages are designed to be built from
source first and foremost -- however it doesn't make much sense to
have a source-based distro full of precompiled binaries and so I do
believe pretty well every developer strives to make this so whenever
possible, given that's sort of our purpose here.





signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Sunday, October 16, 2016 9:19:25 PM EDT Ian Stakenvicius wrote:
> 
> *IF* we were going to make use of upstream vs gentoo-generated binary
> packages in the tree, they *WOULD* block one-another as they would
> collide file-wise at least partially if not completely.  So there
> wouldn't be any testing between the two variants on the same installed
> system.

That was not an argument I was initially making as justification, but via 
slotting and changing names of binaries and/or paths it could be done.

It is in part why systems like eselect exist to switch between 
implementations. In Java's case there is a wrapper around all binaries that is 
called, which handles which ones is used. run-java-tool.bash. In addition to 
things like java-cpnfig etc.

Also why there is gcc-config, binutils-config, etc. Part of the beauty of 
Gentoo 
is installing things that collide, and switching between them for testing.

> > Maybe the upstream binary runs better, does not crash, etc. Or the Gentoo
> > one does. If the Gentoo one is better, it could be used to get a
> > reluctant upstream to make changes. If worse could be used to help figure
> > out where its going wrong.
> 
> OK, so here's how things *actually work* in the gentoo repo:

Because I need such an explanation? I think it could be a little less harsh 
no?

> #1, binary packages aren't made unless there's a really good reason
> for them -- the primary one being that there isn't any other option
> provided by upstream.

Is that a mandated policy? There are ebuilds in tree that are not that way.

> #2, if there is a binary package then the only reason why a gentoo dev
> would roll it instead of using upstream's version is because the
> upstream one fails hard or has too many bugs, security
> vulnerabilities, whatever.  This is as much done on a per-version
> basis within a package as it is on a per-package one.

There is a 3rd case, where the package is to complex to package from source. 
Things like jenkins-bin, and there are others... jenkins can be packaged from 
source, as some others can be. If they were -sbin, maybe more would be aware 
and try to package from source vs use as binary because it is to hard to 
package from source.

> All of this discussion is centered around trying to bring convention
> to a problem that simply doesn't exist.  

Maybe you are just not aware. Which if the packages were required to be named, 
say -sbin a binary that is a from source package, just not packaged you would 
be aware.

They exist, go look! Also seems to be growing.

> Also, if the idea here is to
> open the door for a flood of gentoo-dev-rolled *-bin packages in the
> gentoo repo for end-user convenience,

No that is not the case, and that is done in extreme limited case. I am not 
pushing for more binary packages by any means. It would simply be to 
differentiate, so anyone knows by file name what they are getting, from 
upstream or from Gentoo.

> then we should similarly stop
> this discussion right now too.  How about, instead, you could focus on
> setting up two (additional) repos -- one containing gentoo-built
> binary packages, another containing upstream-only packages.

That is not my goal. I am trying to bring to attention -bin packages in tree. 
-sbin packages should draw attention to get people to package them from 
source.

> That way
> it'll be very obvious to end-users what they'll be using because
> they'll know exactly based on where it comes from. 

This is an issue of things already in tree, and packages being added in tree, 
in Gentoo's repo. Which I obviously cannot do so its not my work.

> It'll also be very
> easy for end-users to control which one is used, just by choosing
> which repo it comes from.  AND, it'll keep them from polluting the
> main gentoo repo too.

It is already polluted, seems you are unaware, but now you know.

Likely wasn't intentional but came across VERY hostile, and completely missing 
the mark and point.

-- 
William L. Thomson Jr.


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

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

[Ian Stakenvicius]

On 16/10/16 06:30 PM, William L. Thomson Jr. wrote:
> On Saturday, October 15, 2016 4:10:51 PM EDT Kent Fredric wrote:
>>
>> Yeah, I get the intent, but I don't see it being likely we'd ever have
>> a real usecase for having both a -bin and a -gbin in tree together.
> 
> 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.


*IF* we were going to make use of upstream vs gentoo-generated binary
packages in the tree, they *WOULD* block one-another as they would
collide file-wise at least partially if not completely.  So there
wouldn't be any testing between the two variants on the same installed
system.



> Maybe the upstream binary runs better, does not crash, etc. Or the Gentoo one 
> does. If the Gentoo one is better, it could be used to get a reluctant 
> upstream to make changes. If worse could be used to help figure out where its 
> going wrong.

OK, so here's how things *actually work* in the gentoo repo:

#1, binary packages aren't made unless there's a really good reason
for them -- the primary one being that there isn't any other option
provided by upstream.

#2, if there is a binary package then the only reason why a gentoo dev
would roll it instead of using upstream's version is because the
upstream one fails hard or has too many bugs, security
vulnerabilities, whatever.  This is as much done on a per-version
basis within a package as it is on a per-package one.

All of this discussion is centered around trying to bring convention
to a problem that simply doesn't exist.  Also, if the idea here is to
open the door for a flood of gentoo-dev-rolled *-bin packages in the
gentoo repo for end-user convenience, then we should similarly stop
this discussion right now too.  How about, instead, you could focus on
setting up two (additional) repos -- one containing gentoo-built
binary packages, another containing upstream-only packages.  That way
it'll be very obvious to end-users what they'll be using because
they'll know exactly based on where it comes from.  It'll also be very
easy for end-users to control which one is used, just by choosing
which repo it comes from.  AND, it'll keep them from polluting the
main gentoo repo too.




signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Saturday, October 15, 2016 4:10:51 PM EDT Kent Fredric wrote:
>
> Yeah, I get the intent, but I don't see it being likely we'd ever have
> a real usecase for having both a -bin and a -gbin in tree together.

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.

> Or similar, given the "deploy binary to system" steps are likely to be
> the same regardless of who built it.

That is an assumption, they might have different dependencies, require 
different changes upon install as a result. Or other things that would have a 
different install phase, but likely most would be the same.

> At best, I'd imagine users who care whether they get "official" binaries
> or "gentoo" binaries would probably prefer to select which as a sort of
> global policy, but that concept is just a doorway to additional complexity.

That could be handled by virtuals.
 
> So a strong argument would have to be made for being able to "select"
> between "Offical" and "Unofficial" binaries in an automated fashion
> before we go down that road to hell.

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.

Maybe the upstream binary runs better, does not crash, etc. Or the Gentoo one 
does. If the Gentoo one is better, it could be used to get a reluctant 
upstream to make changes. If worse could be used to help figure out where its 
going wrong.

I would go even further and do something like -sbin, to represent this is a 
binary of an ebuild that could be built from source. Since there are binaries 
in tree that are closed source cannot. There are also large complex open 
source packages that are in tree as binary due to a lack of man power

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

-- 
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 Saturday, October 15, 2016 5:00:07 PM EDT Austin English wrote:
> On 10/15/2016 05:32 AM, Kristian Fiskerstrand wrote:
> > On 10/14/2016 07:17 PM, William L. Thomson Jr. wrote:
> >> On Friday, October 14, 2016 1:09:25 PM EDT Ian Stakenvicius wrote:
> >>> On 14/10/16 01:05 PM, William L. Thomson Jr. wrote:
>  Problem
>  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.
> >>> 
> >>> Is there a reason that this differentiation would matter?
> >> 
> >> In my opinion yes, the following reasons at minimum
> > 
> > Wouldn't it make more sense to include information on this in
> > metadata.xml rather than specifying it in the package name?
> 
> Yes.

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

Without having to do anything. Doing such via USE flag, description or other 
means would require someone to stop and spend time they would not have to 
otherwise.

Also if many packages are binary, having redundant text in metadata.xml does 
not seem very beneficial. Very likely any text to describe such would be very 
generic.

-- 
William L. Thomson Jr.


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

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

[Austin English]

On 10/15/2016 05:32 AM, Kristian Fiskerstrand wrote:
> On 10/14/2016 07:17 PM, William L. Thomson Jr. wrote:
>> On Friday, October 14, 2016 1:09:25 PM EDT Ian Stakenvicius wrote:
>>> On 14/10/16 01:05 PM, William L. Thomson Jr. wrote:
 Problem
 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.
>>>
>>> Is there a reason that this differentiation would matter?
>>
>> In my opinion yes, the following reasons at minimum
> 
> Wouldn't it make more sense to include information on this in
> metadata.xml rather than specifying it in the package name?
> 

Yes.

-- 
-Austin
GPG: 00B3 2957 B94B F3E1



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 10/14/2016 07:17 PM, William L. Thomson Jr. wrote:
> On Friday, October 14, 2016 1:09:25 PM EDT Ian Stakenvicius wrote:
>> On 14/10/16 01:05 PM, William L. Thomson Jr. wrote:
>>> Problem
>>> 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.
>>
>> Is there a reason that this differentiation would matter?
> 
> In my opinion yes, the following reasons at minimum

Wouldn't it make more sense to include information on this in
metadata.xml rather than specifying it in the package name?

-- 
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

[Kent Fredric]

On Fri, 14 Oct 2016 13:05:43 -0400
"William L. Thomson Jr."  wrote:

> It is some what a moot problem, but I think it would be good to adopt such or 
> similar requirement, maybe in the PMS. Many already follow the -bin suffix 
> now. 
> I just do not believe it is a requirement anywhere. Which if that is the 
> case, 
> I am suggesting it should be. If a package is src_install only, no 
> src_compile, it should be required to have a -bin suffix, or -gbin if self 
> made.

Yeah, I get the intent, but I don't see it being likely we'd ever have
a real usecase for having both a -bin and a -gbin in tree together.

If anything, I'd imagine if that case arose, it would manifest itself more as:

   icedtea-bin + USE=official

Or similar, given the "deploy binary to system" steps are likely to be
the same regardless of who built it.

At best, I'd imagine users who care whether they get "official" binaries
or "gentoo" binaries would probably prefer to select which as a sort of global 
policy,
but that concept is just a doorway to additional complexity.

So a strong argument would have to be made for being able to "select"
between "Offical" and "Unofficial" binaries in an automated fashion
before we go down that road to hell.

( I wrote an example case of how this could be done, and it quickly
went pear shaped and I deleted it[1] )

1: https://gist.github.com/kentfredric/c63e42937c90031834c525dcb6de0da8


pgpb6BVog3iOL.pgp
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Friday, October 14, 2016 4:00:53 PM EDT William Hubbs wrote:
> 
> Remember that src_compile could be in an eclass or the package could be
> using the default src_compile for the EAPI.

FYI, the main Java eclasses, ant and simple, have default src_compile. I have 
lots of Java ebuilds without such. I have modified both those eclasses default 
src_compile with improvements.

I have an open PR that does just that now for auto classpath in Java ebuilds.
https://github.com/gentoo/gentoo/pull/2286

I remember very well that eclasses provide default functions such as that.
I use them all the time :)

-- 
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 Friday, October 14, 2016 4:00:53 PM EDT William Hubbs wrote:
> On Fri, Oct 14, 2016 at 01:05:43PM -0400, William L. Thomson Jr. wrote:
> 
> *snip*
> 
> > If a package is src_install only, no
> > src_compile, it should be required to have a -bin suffix, or -gbin if self
> > made.
> I disagree with this.
> 
> Remember that src_compile could be in an eclass or the package could be
> using the default src_compile for the EAPI.
> 
> Also there may be no need to compile anything; the package may just be
> scripts, data files or documentation of some kind.

I was implying something that did not build/compile. All mentioned would be 
obvious exceptions, as they are clearly not binary only.

The requirement would be for binary only packages.

An ebuild using src_compile from a eclass is likely not a binary only package. 
An ebuild installing scripts, text. xml, patches, etc would not be considered 
a binary only package either.

-- 
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 Hubbs]

On Fri, Oct 14, 2016 at 01:05:43PM -0400, William L. Thomson Jr. wrote:

*snip*

> If a package is src_install only, no 
> src_compile, it should be required to have a -bin suffix, or -gbin if self 
> made.

I disagree with this.

Remember that src_compile could be in an eclass or the package could be
using the default src_compile for the EAPI.

Also there may be no need to compile anything; the package may just be
scripts, data files or documentation of some kind.


Thanks,

William



signature.asc
Description: Digital signature

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

[William L. Thomson Jr.]

On Friday, October 14, 2016 8:15:35 PM EDT Ulrich Mueller wrote:
>
> > The devmanual has the same info as in the PMS including on the suffix
> > https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-33.2
> 
> That section is about version suffixes (like _beta or _rc), not about
> package names.

I am aware, the one I posted initially was about package names. I was just 
showing the PMS in various sections says the same thing as the devmanual in 
condensed form.

> If anything at all, it would be a naming convention specific to the
> gentoo repository. Others' repositories can follow different rules.

It seems others already do this, like exherbo pretty sure Funtoo is the same. 
They also use the -bin naming  scheme for binaries. Not aware of other distros 
using PMS. For self built, may go with -ebin vs -gbin for universal use.

I just wanted to standardize use of such. I see -bin's in places but I have 
never seen any document say it should be done, it is required, etc. Some 
binary packages do not have that. Should they? Nothing says they are required 
to, thus the suggested requirement.

No worries either way, just wanted to standardize things.

-- 
William L. Thomson Jr.


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

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

[Ulrich Mueller]

> On Fri, 14 Oct 2016, William L Thomson wrote:

> On Friday, October 14, 2016 1:36:20 PM EDT Mike Gilbert wrote:
>> 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.

> I was not sure if PMS was the right place. It may be better suited
> in the devmanual. Though both seem to say the same thing, just more
> verbose in devmanual than than PMS.

> https://devmanual.gentoo.org/ebuild-writing/file-format/

> The devmanual has the same info as in the PMS including on the suffix
> https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-33.2

That section is about version suffixes (like _beta or _rc), not about
package names.

> Which is why I assumed PMS was the proper place. They seem to be the
> same at this time. None of it seemed Gentoo specific.

It doesn't affect operation of the package manager at all, so it
certainly doesn't belong in PMS.

If anything at all, it would be a naming convention specific to the
gentoo repository. Others' repositories can follow different rules.

Ulrich


pgpMrWEZ4MjFK.pgp
Description: PGP signature

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

[William L. Thomson Jr.]

On Friday, October 14, 2016 1:36:20 PM EDT Mike Gilbert wrote:
>
> 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.

I was not sure if PMS was the right place. It may be better suited in the 
devmanual. Though both seem to say the same thing, just more verbose in 
devmanual than than PMS.

https://devmanual.gentoo.org/ebuild-writing/file-format/

The devmanual has the same info as in the PMS including on the suffix
https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-33.2

Which is why I assumed PMS was the proper place. They seem to be the same at 
this time. None of it seemed Gentoo specific. 

-- 
William L. Thomson Jr.


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

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

[Mike Gilbert]

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.

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

[Ian Stakenvicius]

On 14/10/16 01:17 PM, William L. Thomson Jr. wrote:
> On Friday, October 14, 2016 1:09:25 PM EDT Ian Stakenvicius wrote:
>> On 14/10/16 01:05 PM, William L. Thomson Jr. wrote:
>>> Problem
>>> 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.
>>
>> Is there a reason that this differentiation would matter?
> 
> In my opinion yes, the following reasons at minimum
> 
> 1. Upstream binary little can be done if there are issues. Maybe changing 
> things on the system, but cannot change what it was built/linked against etc. 
> Bugs there would be filed against upstream, not really Gentoo as there is 
> nothing that can be done to change the binary itself.
> 
> 2. Gentoo made binaries can be remade if there are issues. Bugs on those 
> should be filed against Gentoo rather than upstream. There is also a process 
> to 
> making those binaries. It may be as simple as emerging a Gentoo package and 
> creating a tarball, or it may not. Others may need to know how to do such if 
> someone moves on. Most times that is not documented, and people have no idea 
> if the binary was made for Gentoo on Gentoo, or just re-packaged upstream.
> 
> 3. The obvious reason to have a -bin in general, is to let anyone know they 
> are merging a binary package. Which may or may not be wanted. Also shows what 
> packages may need to be packaged from source if possible. People may choose 
> to 
> emerge a self made Gentoo binary more often than say a third party one. Since 
> they know it was built on a Gentoo system, just saves them from having to 
> compile themselves. They also may trust a Gentoo made binary more than one 
> from upstream, but that is speculative.
> 
> Mostly reasons 1 and 2, 3 is a side benefit but not the major rational.
> 

So, #1, if there's a problem we should still have bugs in gentoo's
bugzilla -- there may be little that can be done to the package but if
the issue is with integration into the rest of gentoo that is
absolutely within the realm of the maintainer to address.  Either way,
having the package's name indicate if its an upstream binary or not is
rather moot to this one.

#2, see #1 regarding bugs; regarding maintenance, this isn't a whole
lot different from training replacement devs in how to handle a
foreign build system or managing very complex configuration options --
that is, instructions or documentation or helper scripts should be
made available and shared somewhere not in the package.  Having the
package name indicate upstream-bin vs gentoo-bin doesn't help this one
either.

#3, this may have merit in terms of using an alternate package name
for upstream vs gentoo rolled binaries, but realistically i'm not
seeing a need for the separation in the package's NAME unless we're
going to have both gento-rolled and upstream-rolled binaries in the
repo at the same time, competing with eachother.  It would be just as
effective IMO to list if the package is gentoo-rolled or not in its
description in metadata, no need to (re)define the package name.





signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Friday, October 14, 2016 1:09:25 PM EDT Ian Stakenvicius wrote:
> On 14/10/16 01:05 PM, William L. Thomson Jr. wrote:
> > Problem
> > 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.
> 
> Is there a reason that this differentiation would matter?

In my opinion yes, the following reasons at minimum

1. Upstream binary little can be done if there are issues. Maybe changing 
things on the system, but cannot change what it was built/linked against etc. 
Bugs there would be filed against upstream, not really Gentoo as there is 
nothing that can be done to change the binary itself.

2. Gentoo made binaries can be remade if there are issues. Bugs on those 
should be filed against Gentoo rather than upstream. There is also a process to 
making those binaries. It may be as simple as emerging a Gentoo package and 
creating a tarball, or it may not. Others may need to know how to do such if 
someone moves on. Most times that is not documented, and people have no idea 
if the binary was made for Gentoo on Gentoo, or just re-packaged upstream.

3. The obvious reason to have a -bin in general, is to let anyone know they 
are merging a binary package. Which may or may not be wanted. Also shows what 
packages may need to be packaged from source if possible. People may choose to 
emerge a self made Gentoo binary more often than say a third party one. Since 
they know it was built on a Gentoo system, just saves them from having to 
compile themselves. They also may trust a Gentoo made binary more than one 
from upstream, but that is speculative.

Mostly reasons 1 and 2, 3 is a side benefit but not the major rational.

-- 
William L. Thomson Jr.


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

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

[Ian Stakenvicius]

On 14/10/16 01:05 PM, William L. Thomson Jr. wrote:
> Problem
> 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.

Is there a reason that this differentiation would matter?





signature.asc
Description: OpenPGP digital signature