Re: [Rpm-maint] Drowning in build-ids

2017-11-08 Thread Panu Matilainen 

On 10/25/2017 06:28 PM, Neal Gompa wrote:

On Wed, Oct 25, 2017 at 7:30 AM, Panu Matilainen  wrote:

On 10/25/2017 02:06 PM, Mark Wielaard wrote:


On Wed, 2017-10-25 at 12:49 +0200, Igor Gnatenko wrote:


On Wed, 2017-10-25 at 13:46 +0300, Panu Matilainen wrote:
So I'm wondering how to make this less ugly.



The first thing that comes to mind is adding a %hidden virtual
attribute
and using it on build-ids (which are in a hidden directory on the
filesystem), which would hide such files rpm -ql etc output by
default
(but with a cli-switch to show it all).

Another option would be hiding files and directories starting with
dot,
ie mirror the filesystem behavior. Obviously with a switch to show
them too.

The idea of being able to hide arbitrary files from default output
makes
me a bit queasy. And also %hidden wouldn't help with existing
packages,
(mass) rebuilds are needed with that option. So it seems like two
points
in favor of the fs behavior, but dunno.

Thoughts, comments, better ideas?



I definitely like FS approach (2). But also having %hidden (1) would
find its use I think.



I don't like the name %hidden, but I think that having an official
attribute like "%artificial" might be the correct way to go. Then any
file added by rpm/file trigger/etc that wasn't explicitly mentioned in
the spec %files list could get that attribute. If you have that then
you can have a rpm -qA to list all "artificial" files of the rpm (and
rpm -qlA would show all).



I don't really like it either. Actually the very first idea I had was to
simply add build-id's as a virtual attribute of their own, ie %buildid, and
callers/users could then decide whether they want to see them or not. But it
seemed a bit limiting (what if we grow more data like this in the future) so
I came up with "hidden", but those are entirely different kinds of concepts.


I don't like the hide .dot files heuristic. People might have
explicitly added .dot files to their spec %files. Then I think they
should be shown by default I think.



There's that, yes.


But maybe explicitly treat /.build-id/ as artificial and then add an
official %artificial for all "future" use would be a good compromise?



Yeah, %artificial would be more like "build-id concept broadened", as
opposed to "hidden" which is something completely different. Inspired by
that, %artifact would also seem fairly fitting.



The %artifact marker would make sense for things like Python pycache
files too. And if package generators get implemented, then broadly
speaking, this would allow making these things done more or less
automatically.



Okay, support for %artifact added in commit 
6f1e75ddd2c67eb8b43608c03bf0cc895612e6fe, thanks for your input guys!


I'll post a patch adding artifact markers to the relevant debuginfo 
artifacts for review shortly.


- Panu -
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] Drowning in build-ids

2017-10-25 Thread Panu Matilainen 

On 10/25/2017 02:06 PM, Mark Wielaard wrote:

On Wed, 2017-10-25 at 12:49 +0200, Igor Gnatenko wrote:

On Wed, 2017-10-25 at 13:46 +0300, Panu Matilainen wrote:
So I'm wondering how to make this less ugly.


The first thing that comes to mind is adding a %hidden virtual
attribute
and using it on build-ids (which are in a hidden directory on the
filesystem), which would hide such files rpm -ql etc output by
default
(but with a cli-switch to show it all).

Another option would be hiding files and directories starting with
dot,
ie mirror the filesystem behavior. Obviously with a switch to show
them too.

The idea of being able to hide arbitrary files from default output
makes
me a bit queasy. And also %hidden wouldn't help with existing
packages,
(mass) rebuilds are needed with that option. So it seems like two
points
in favor of the fs behavior, but dunno.

Thoughts, comments, better ideas?


I definitely like FS approach (2). But also having %hidden (1) would
find its use I think.


I don't like the name %hidden, but I think that having an official
attribute like "%artificial" might be the correct way to go. Then any
file added by rpm/file trigger/etc that wasn't explicitly mentioned in
the spec %files list could get that attribute. If you have that then
you can have a rpm -qA to list all "artificial" files of the rpm (and
rpm -qlA would show all).


I don't really like it either. Actually the very first idea I had was to 
simply add build-id's as a virtual attribute of their own, ie %buildid, 
and callers/users could then decide whether they want to see them or 
not. But it seemed a bit limiting (what if we grow more data like this 
in the future) so I came up with "hidden", but those are entirely 
different kinds of concepts.



I don't like the hide .dot files heuristic. People might have
explicitly added .dot files to their spec %files. Then I think they
should be shown by default I think.


There's that, yes.


But maybe explicitly treat /.build-id/ as artificial and then add an
official %artificial for all "future" use would be a good compromise?


Yeah, %artificial would be more like "build-id concept broadened", as 
opposed to "hidden" which is something completely different. Inspired by 
that, %artifact would also seem fairly fitting.


- Panu -


Cheers,

Mark



___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] Drowning in build-ids

2017-10-25 Thread Mark Wielaard 
On Wed, 2017-10-25 at 12:49 +0200, Igor Gnatenko wrote:
> On Wed, 2017-10-25 at 13:46 +0300, Panu Matilainen wrote:
> So I'm wondering how to make this less ugly.
> > 
> > The first thing that comes to mind is adding a %hidden virtual
> > attribute 
> > and using it on build-ids (which are in a hidden directory on the 
> > filesystem), which would hide such files rpm -ql etc output by
> > default 
> > (but with a cli-switch to show it all).
> > 
> > Another option would be hiding files and directories starting with
> > dot, 
> > ie mirror the filesystem behavior. Obviously with a switch to show
> > them too.
> > 
> > The idea of being able to hide arbitrary files from default output
> > makes 
> > me a bit queasy. And also %hidden wouldn't help with existing
> > packages, 
> > (mass) rebuilds are needed with that option. So it seems like two
> > points 
> > in favor of the fs behavior, but dunno.
> > 
> > Thoughts, comments, better ideas?
> 
> I definitely like FS approach (2). But also having %hidden (1) would
> find its use I think.

I don't like the name %hidden, but I think that having an official
attribute like "%artificial" might be the correct way to go. Then any
file added by rpm/file trigger/etc that wasn't explicitly mentioned in
the spec %files list could get that attribute. If you have that then
you can have a rpm -qA to list all "artificial" files of the rpm (and
rpm -qlA would show all).

I don't like the hide .dot files heuristic. People might have
explicitly added .dot files to their spec %files. Then I think they
should be shown by default I think.

But maybe explicitly treat /.build-id/ as artificial and then add an
official %artificial for all "future" use would be a good compromise?

Cheers,

Mark
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] Drowning in build-ids

2017-10-25 Thread Igor Gnatenko 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2017-10-25 at 13:46 +0300, Panu Matilainen wrote:
> I've only now begun to encounter packages with the build-id links in
> the 
> packages themselves. In a package with just a couple of binaries
> it's 
> seemed like non-issue, but yesterday I happened to encounter this:
> 
> [pmatilai@sopuli x86_64]$ rpm -qpl can-utils-20170830git-
> 1.fc28.x86_64.rpm
> /usr/bin/asc2log
> /usr/bin/bcmserver
> /usr/bin/can-calc-bit-timing
> /usr/bin/canbusload
> /usr/bin/candump
> /usr/bin/canfdtest
> /usr/bin/cangen
> /usr/bin/cangw
> /usr/bin/canlogserver
> /usr/bin/canplayer
> /usr/bin/cansend
> /usr/bin/cansniffer
> /usr/bin/isotpdump
> /usr/bin/isotpperf
> /usr/bin/isotprecv
> /usr/bin/isotpsend
> /usr/bin/isotpserver
> /usr/bin/isotpsniffer
> /usr/bin/isotptun
> /usr/bin/log2asc
> /usr/bin/log2long
> /usr/bin/slcan_attach
> /usr/bin/slcand
> /usr/bin/slcanpty
> /usr/lib/.build-id
> /usr/lib/.build-id/05
> /usr/lib/.build-id/05/c6e0445041bc297383997257bb625809ba62cb
> /usr/lib/.build-id/0a
> /usr/lib/.build-id/0a/60db326d39a38847a3f6c6bb67213434399c42
> /usr/lib/.build-id/0a/7395e63809014439634b0f1c311b40a05fb5e5
> /usr/lib/.build-id/1a
> /usr/lib/.build-id/1a/cd09a44512470d5376a5abee7438005b3de0a2
> /usr/lib/.build-id/24
> /usr/lib/.build-id/24/c4eb684e21826207dc1d71bc023cdef7b5ee88
> /usr/lib/.build-id/3a
> /usr/lib/.build-id/3a/2309e9e68c2e3cdf475734b7eb4f426f109926
> /usr/lib/.build-id/3f
> /usr/lib/.build-id/3f/cd554bc60888e7feb4fb3d4cb891c549361aed
> /usr/lib/.build-id/59
> /usr/lib/.build-id/59/c1638a4c15139492927c117d44cc6f84532464
> /usr/lib/.build-id/5b
> /usr/lib/.build-id/5b/c0f8af0212d1e94f8a5c962b719dbe3f4dcc50
> /usr/lib/.build-id/6a
> /usr/lib/.build-id/6a/187c01913bc9b861dcb95ac0c5a12865fdd93b
> /usr/lib/.build-id/6a/47c3475fbe4303a8a8005353f11f719112f838
> /usr/lib/.build-id/71
> /usr/lib/.build-id/71/f3b492130fa6ae09354107a8d7821d2969a4d9
> /usr/lib/.build-id/75
> /usr/lib/.build-id/75/a05d7dd3d81d9f7c0eef1ebde082cc1a5c93d9
> /usr/lib/.build-id/7d
> /usr/lib/.build-id/7d/2f0e2ceb4580c3ccd865e689bce9beb3a20903
> /usr/lib/.build-id/7e
> /usr/lib/.build-id/7e/ac33ea6338f316f03476c70f7c2d3743104a68
> /usr/lib/.build-id/8a
> /usr/lib/.build-id/8a/40a26934006152ad167875b61497065cbe3f7e
> /usr/lib/.build-id/9e
> /usr/lib/.build-id/9e/1b2107379d4830ecf3da8c29faf8e558c1eac2
> /usr/lib/.build-id/b0
> /usr/lib/.build-id/b0/ca696ceaa3a1e54722483ee55c5b12883d44f0
> /usr/lib/.build-id/b3
> /usr/lib/.build-id/b3/90fe4f2ac3dcea04aacf34b46b858466626a2e
> /usr/lib/.build-id/c6
> /usr/lib/.build-id/c6/645447744a17cc09f175e4d1f3bd8a441e1563
> /usr/lib/.build-id/db
> /usr/lib/.build-id/db/84b0bc26c9bb0eadc88a8ecde185e3db6452ba
> /usr/lib/.build-id/f3
> /usr/lib/.build-id/f3/5c37a5dc142928053784cb072403988b0f65dc
> /usr/lib/.build-id/fb
> /usr/lib/.build-id/fb/46eef57284d7136974be48fba4b0550a86c998
> /usr/lib/.build-id/fc
> /usr/lib/.build-id/fc/e691679c6ac99d2940daf63c6fe3221ee1af77
> /usr/share/doc/can-utils
> /usr/share/doc/can-utils/README.md
> /usr/share/licenses/can-utils
> /usr/share/licenses/can-utils/COPYING
> [pmatilai@sopuli x86_64]$
> 
> I typically use 80x35 terminals and even on that, what you end up
> seeing 
> is the hex gibberish of build-ids that is totally irrelevant for
> most 
> people completely dominates the output that used to be spot-on
> relevant. 
> Not good.
> 
> So I'm wondering how to make this less ugly.
> 
> The first thing that comes to mind is adding a %hidden virtual
> attribute 
> and using it on build-ids (which are in a hidden directory on the 
> filesystem), which would hide such files rpm -ql etc output by
> default 
> (but with a cli-switch to show it all).
> 
> Another option would be hiding files and directories starting with
> dot, 
> ie mirror the filesystem behavior. Obviously with a switch to show
> them too.
> 
> The idea of being able to hide arbitrary files from default output
> makes 
> me a bit queasy. And also %hidden wouldn't help with existing
> packages, 
> (mass) rebuilds are needed with that option. So it seems like two
> points 
> in favor of the fs behavior, but dunno.
> 
> Thoughts, comments, better ideas?
I definitely like FS approach (2). But also having %hidden (1) would
find its use I think.
> 
>   - Panu -
> ___
> Rpm-maint mailing list
> Rpm-maint@lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-maint

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlnwbCsACgkQaVcUvRu8
X0yPsg/+NYPUDYV+TX4aqUB9rJ6q7OI7Mcg2w8HSobSI0KLFM3zFIO86MUyGA5Uo
Bi7Od3TkXIXxYrGHL14Obh7cb9gVl0RStRo6SyTBrxIvOSAYPi2MpE+bG+O0eVPZ
16GfDZEZfADVwoRq5APUwYbQrF4gExq4jhZDsL2brwQ7dWf4pWnam9CcdrYEYIdB
rXtx43t9NQfc8d0gYG/gFP3Ntqsbhslrbfip/1+Ff0lwh14QsHSKGVbs8X3o897K
/iVRhX9ocvjRyWfIPaZ22bRfAj0bv78P08l5ki2xRs7K7okjgyhW3DzPqmdZeJ9S
1e5FNHOM0t6et1J3BfB8vfiwL3PG2ue9NdnIOd61nPPIaNgZK50gzrUN/z3w3NL5

[Rpm-maint] Drowning in build-ids

2017-10-25 Thread Panu Matilainen 
I've only now begun to encounter packages with the build-id links in the 
packages themselves. In a package with just a couple of binaries it's 
seemed like non-issue, but yesterday I happened to encounter this:


[pmatilai@sopuli x86_64]$ rpm -qpl can-utils-20170830git-1.fc28.x86_64.rpm
/usr/bin/asc2log
/usr/bin/bcmserver
/usr/bin/can-calc-bit-timing
/usr/bin/canbusload
/usr/bin/candump
/usr/bin/canfdtest
/usr/bin/cangen
/usr/bin/cangw
/usr/bin/canlogserver
/usr/bin/canplayer
/usr/bin/cansend
/usr/bin/cansniffer
/usr/bin/isotpdump
/usr/bin/isotpperf
/usr/bin/isotprecv
/usr/bin/isotpsend
/usr/bin/isotpserver
/usr/bin/isotpsniffer
/usr/bin/isotptun
/usr/bin/log2asc
/usr/bin/log2long
/usr/bin/slcan_attach
/usr/bin/slcand
/usr/bin/slcanpty
/usr/lib/.build-id
/usr/lib/.build-id/05
/usr/lib/.build-id/05/c6e0445041bc297383997257bb625809ba62cb
/usr/lib/.build-id/0a
/usr/lib/.build-id/0a/60db326d39a38847a3f6c6bb67213434399c42
/usr/lib/.build-id/0a/7395e63809014439634b0f1c311b40a05fb5e5
/usr/lib/.build-id/1a
/usr/lib/.build-id/1a/cd09a44512470d5376a5abee7438005b3de0a2
/usr/lib/.build-id/24
/usr/lib/.build-id/24/c4eb684e21826207dc1d71bc023cdef7b5ee88
/usr/lib/.build-id/3a
/usr/lib/.build-id/3a/2309e9e68c2e3cdf475734b7eb4f426f109926
/usr/lib/.build-id/3f
/usr/lib/.build-id/3f/cd554bc60888e7feb4fb3d4cb891c549361aed
/usr/lib/.build-id/59
/usr/lib/.build-id/59/c1638a4c15139492927c117d44cc6f84532464
/usr/lib/.build-id/5b
/usr/lib/.build-id/5b/c0f8af0212d1e94f8a5c962b719dbe3f4dcc50
/usr/lib/.build-id/6a
/usr/lib/.build-id/6a/187c01913bc9b861dcb95ac0c5a12865fdd93b
/usr/lib/.build-id/6a/47c3475fbe4303a8a8005353f11f719112f838
/usr/lib/.build-id/71
/usr/lib/.build-id/71/f3b492130fa6ae09354107a8d7821d2969a4d9
/usr/lib/.build-id/75
/usr/lib/.build-id/75/a05d7dd3d81d9f7c0eef1ebde082cc1a5c93d9
/usr/lib/.build-id/7d
/usr/lib/.build-id/7d/2f0e2ceb4580c3ccd865e689bce9beb3a20903
/usr/lib/.build-id/7e
/usr/lib/.build-id/7e/ac33ea6338f316f03476c70f7c2d3743104a68
/usr/lib/.build-id/8a
/usr/lib/.build-id/8a/40a26934006152ad167875b61497065cbe3f7e
/usr/lib/.build-id/9e
/usr/lib/.build-id/9e/1b2107379d4830ecf3da8c29faf8e558c1eac2
/usr/lib/.build-id/b0
/usr/lib/.build-id/b0/ca696ceaa3a1e54722483ee55c5b12883d44f0
/usr/lib/.build-id/b3
/usr/lib/.build-id/b3/90fe4f2ac3dcea04aacf34b46b858466626a2e
/usr/lib/.build-id/c6
/usr/lib/.build-id/c6/645447744a17cc09f175e4d1f3bd8a441e1563
/usr/lib/.build-id/db
/usr/lib/.build-id/db/84b0bc26c9bb0eadc88a8ecde185e3db6452ba
/usr/lib/.build-id/f3
/usr/lib/.build-id/f3/5c37a5dc142928053784cb072403988b0f65dc
/usr/lib/.build-id/fb
/usr/lib/.build-id/fb/46eef57284d7136974be48fba4b0550a86c998
/usr/lib/.build-id/fc
/usr/lib/.build-id/fc/e691679c6ac99d2940daf63c6fe3221ee1af77
/usr/share/doc/can-utils
/usr/share/doc/can-utils/README.md
/usr/share/licenses/can-utils
/usr/share/licenses/can-utils/COPYING
[pmatilai@sopuli x86_64]$

I typically use 80x35 terminals and even on that, what you end up seeing 
is the hex gibberish of build-ids that is totally irrelevant for most 
people completely dominates the output that used to be spot-on relevant. 
Not good.


So I'm wondering how to make this less ugly.

The first thing that comes to mind is adding a %hidden virtual attribute 
and using it on build-ids (which are in a hidden directory on the 
filesystem), which would hide such files rpm -ql etc output by default 
(but with a cli-switch to show it all).


Another option would be hiding files and directories starting with dot, 
ie mirror the filesystem behavior. Obviously with a switch to show them too.


The idea of being able to hide arbitrary files from default output makes 
me a bit queasy. And also %hidden wouldn't help with existing packages, 
(mass) rebuilds are needed with that option. So it seems like two points 
in favor of the fs behavior, but dunno.


Thoughts, comments, better ideas?

- Panu -
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint