Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #246306 > unrolled thread

packages built with golang

Back to article view | Back to linux.debian.user

Contents

  packages built with golang Cousin Stanley <cousinstanley@gmail.com> - 2022-03-14 21:20 +0100
    Re: packages built with golang Andy Smith <andy@strugglers.net> - 2022-03-14 22:10 +0100
      Re: packages built with golang Cousin Stanley <cousinstanley@gmail.com> - 2022-03-15 01:00 +0100
        Re: packages built with golang David Wright <deblis@lionunicorn.co.uk> - 2022-03-15 01:20 +0100
          Re: packages built with golang Cousin Stanley <cousinstanley@gmail.com> - 2022-03-15 02:00 +0100
            Re: packages built with golang Greg Wooledge <greg@wooledge.org> - 2022-03-15 02:40 +0100
    Re: packages built with golang Dan Ritter <dsr@randomstring.org> - 2022-03-14 22:30 +0100
      Re: packages built with golang Cousin Stanley <cousinstanley@gmail.com> - 2022-03-15 01:50 +0100
        Re: packages built with golang <tomas@tuxteam.de> - 2022-03-15 07:30 +0100
          Re: packages built with golang Cousin Stanley <cousinstanley@gmail.com> - 2022-03-15 15:00 +0100
            Re: packages built with golang Dan Ritter <dsr@randomstring.org> - 2022-03-15 15:20 +0100
              Re: packages built with golang Cousin Stanley <cousinstanley@gmail.com> - 2022-03-15 16:50 +0100
                Re: packages built with golang Greg Wooledge <greg@wooledge.org> - 2022-03-15 17:00 +0100
                Re: packages built with golang Kushal Kumaran <kushal@locationd.net> - 2022-03-15 17:00 +0100
                Re: packages built with golang Curt <curty@free.fr> - 2022-03-15 19:00 +0100
                Re: packages built with golang Dan Ritter <dsr@randomstring.org> - 2022-03-15 19:00 +0100
                  Re: packages built with golang Cindy Sue Causey <butterflybytes@gmail.com> - 2022-03-16 03:20 +0100
                    Re: packages built with golang Cousin Stanley <cousinstanley@gmail.com> - 2022-03-17 00:50 +0100
            Re: packages built with golang <tomas@tuxteam.de> - 2022-03-15 16:40 +0100
    Re: packages built with golang songbird <songbird@anthive.com> - 2022-03-15 03:30 +0100

#246306 — packages built with golang

  Reading this newsgroup earlier today
  someone mentioned the  hugo  package
  for static site generation.

  I was curious about the package
  so I tried .... 

    $ apt-cache show hugo

  The usual package information was returned
  along with, in my opinion, an unsightly mess
  entailing a long string of 88 entries 
  naming individual golang packages 
  following Built-Using:

  A simple message such as the following 
  might be sufficient ....

    Built-Using:  golang , golang libraries and packages

  I have seen this with a few packages other than hugo
  that were built using golang as well.


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [next] | [standalone]

#246307

Hello,

On Mon, Mar 14, 2022 at 12:53:21PM -0700, Cousin Stanley wrote:
>     $ apt-cache show hugo
> 
>   The usual package information was returned
>   along with, in my opinion, an unsightly mess
>   entailing a long string of 88 entries 
>   naming individual golang packages 
>   following Built-Using:
> 
>   A simple message such as the following 
>   might be sufficient ....
> 
>     Built-Using:  golang , golang libraries and packages

As far as I understand it this is needed because being a static
binary, the hugo package would need to be rebuilt whenever any of
the go packages it depends upon is changed.

So this information is needed for the developers and packagers, but
I suppose you could argue that it is information overload for the
casual user of "apt show".

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#246311

Andy Smith wrote:

> ....
> So this information is needed for the developers and packagers, 
> but I suppose you could argue that it is information overload 
> for the casual user of "apt show".

  It seems to be information overload for me pesonally.

  Perhaps a link to the relevant golang list
  using the  hugo  package as an example
  ah lah ....

    Complete documentation 
    is available at https://gohugo.io/

    Complete golang package used list
    is available at .... 


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [prev] | [next] | [standalone]

#246312

On Mon 14 Mar 2022 at 16:33:42 (-0700), Cousin Stanley wrote:
> Andy Smith wrote:
> > ....
> > So this information is needed for the developers and packagers, 
> > but I suppose you could argue that it is information overload 
> > for the casual user of "apt show".
> 
>   It seems to be information overload for me pesonally.
> 
>   Perhaps a link to the relevant golang list
>   using the  hugo  package as an example
>   ah lah ....
> 
>     Complete documentation 
>     is available at https://gohugo.io/
> 
>     Complete golang package used list
>     is available at .... 

How about:

$ apt-cache show hugo | grep -v '^Built-Using:'

which you could wrap into a function.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#246314

David Wright wrote:

> How about:
> 
> $ apt-cache show hugo | grep -v '^Built-Using:'
> 
> which you could wrap into a function.
> 

  I don't mind the  Built-Using  list at all
  for reasonable sized lists and I wouldn't
  care to remove it altogether.

  I can use your suggestion to remove it
  after I have first seen a  l o n g  list
  for a more tidy view of packages
  that I was not familar with.


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [prev] | [next] | [standalone]

#246315

On Mon, Mar 14, 2022 at 05:37:30PM -0700, Cousin Stanley wrote:
> David Wright wrote:
> 
> > How about:
> > 
> > $ apt-cache show hugo | grep -v '^Built-Using:'
> > 
> > which you could wrap into a function.
> > 
> 
>   I don't mind the  Built-Using  list at all
>   for reasonable sized lists and I wouldn't
>   care to remove it altogether.

Here's one example of a thing you could do:

apt-cache() {
    command apt-cache "$@" |
    awk '/^Built-Using:/ {if (length > 80) print "Built-Using: MANY THINGS";
			  else print; next}
	1'
    return "${PIPESTATUS[0]}"
}

And I found some packages to test it with:

    grub-efi-amd64-signed
    libguice-java
    libsisu-guice-java
    hugo

That was almost as tricky as writing the wrapper function.

[toc] | [prev] | [next] | [standalone]

#246309

Cousin Stanley wrote: 
>   Reading this newsgroup earlier today
>   someone mentioned the  hugo  package
>   for static site generation.
> 
>   I was curious about the package
>   so I tried .... 
> 
>     $ apt-cache show hugo
> 
>   The usual package information was returned
>   along with, in my opinion, an unsightly mess
>   entailing a long string of 88 entries 
>   naming individual golang packages 
>   following Built-Using:
> 
>   A simple message such as the following 
>   might be sufficient ....
> 
>     Built-Using:  golang , golang libraries and packages
> 
>   I have seen this with a few packages other than hugo
>   that were built using golang as well.

Oh, no.

An ordinary package is built with, say, glibc and openssl and a
couple of parsers. All of them are already in Debian, so they go
into the Depends categories. Each of them have their own
dependencies, but you mostly don't have to install them because
they are already on your system.

When a Go package is built, it probably has about the same
number of libraries that it depends on, but because Go is
static, all of them have to be linked in to the binary that gets
built and distributed.

Now, when there's a problem in libfoo=2.1 which allows anyone to
supply the password NSA31415926535 for authentication as root,
Debian has to issue libfoo=2.2 as a security update. Every
package that uses libfoo gets fixed at the same time. (Running
programs may need to be restarted.)

If the same problem is in go-foo, every package that was
Built-Using go-foo needs to be tracked down, rebuilt, and a
separate security update issued.

Not having Built-Using is just like not having dependencies.

-dsr-

[toc] | [prev] | [next] | [standalone]

#246313

Dan Ritter wrote:

> ....
> Not having Built-Using is just like not having dependencies.

  Thanks for the explanation.

  I can understand the need for the Built-Using list
  for the developers that need it. 

  In cases such as that for the  l o n g  list
  returned for golang built packages like hugo
  perhaps returning a link to the required list
  might work avoiding what Andy Smith
  referred to as information overload 
  and that would save a bit of bandwidth 
  as a bonus since those  l o n g  lists 
  go out to all readers .... :-)
   

-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [prev] | [next] | [standalone]

#246317

[Multipart message — attachments visible in raw view] — view raw

On Mon, Mar 14, 2022 at 05:23:02PM -0700, Cousin Stanley wrote:
> Dan Ritter wrote:
> 
> > ....
> > Not having Built-Using is just like not having dependencies.
> 
>   Thanks for the explanation.
> 
>   I can understand the need for the Built-Using list
>   for the developers that need it. 

No, it seems you haven't understood.

Assume some security issue becomes known for, say, libssl.

The developers fix it. The Debian developer integrates the fix into
the package (if necessary, by backporting. You, the user, do an
apt-get upgrade. The fixed version gets installed in your system,
every program using that library is now fine.

With go, you have, say, some crypto library linked STATICALLY to
15 programs from as many packages. The bug gets fixed and...
nothing happens. Unless... your system knows that those 15 packages
were "Built-Using:".

That's why you need that metadata.

As for why they are shown to you, the system administrator --
well, the installer's decision to install those 15 packages
has to be transparent to you. It is, after all, the dark
sister of "Depends:" in the statical linking world.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#246321

tomas@tuxteam.de wrote:

> No, it seems you haven't understood.
> ....

  I assure you that I do understand the need 
  for access to the Built-Using list. 

  What I don't understand is the necessity
  to transmit a string of 3933 bytes
  for 87 golang packages for example 
  when a link to the same would suffice 
  for those that actually require it.

  As a casual user only perusing package information
  for an introductory cursory look,
  a list entailing that level of detail 
  doesn't seem to be necessary. 


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [prev] | [next] | [standalone]

#246322

Cousin Stanley wrote: 
> tomas@tuxteam.de wrote:
> 
> > No, it seems you haven't understood.
> > ....
> 
>   I assure you that I do understand the need 
>   for access to the Built-Using list. 
> 
>   What I don't understand is the necessity
>   to transmit a string of 3933 bytes
>   for 87 golang packages for example 
>   when a link to the same would suffice 
>   for those that actually require it.

The package manager needs it. Whether or not you want to see it
is a different issue. The data is already on your system, so
there's no transmission happening.


>   As a casual user only perusing package information
>   for an introductory cursory look,
>   a list entailing that level of detail 
>   doesn't seem to be necessary. 

You have options. Greg provided you with one.

-dsr-

[toc] | [prev] | [next] | [standalone]

#246324

Cousin Stanley wrote :

>> What I don't understand is the necessity
>> to transmit a string of 3933 bytes
>> for 87 golang packages for example
>> when a link to the same would suffice
>> for those that actually require it.

Dan Ritter wrote :

> The package manager needs it. 

  I understand this.

> Whether or not you want to see it
> is a different issue. 

  I understand this.

> The data is already on your system, so
> there's no transmission happening.

  I do  not  understand this.

  I was under the impression that 
  package information returned by ....

    apt-cache show some-package

  for packages that I have not installed
  would not be downloaded onto my system
  until I actually requested it.

  If that  is  the case then a transmission
  would be happening when one made
  such a request.

  Does the Debian package manager
  really download package information
  for  all  ~59,000  avaiilabel packages 
  in anticipation that users will need it 
  at sometime in the future ?

  That would be suprising to me.
  
  On the Debian Bullseye system that I'm currently using 
  I only have a fraction of the available packages installed .... 

    $ dpkg -l | wc -l
      2366

> 
> You have options. Greg provided you with one.

  I understand this and the use of grep -v ....
  to supress output and fully appreciate the suggestion.

  However, in such cases as the long Built-Using examples,
  the so-called  information overload  has already ocured
  which might have been saved if a link had been provided
  instead.

   

-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [prev] | [next] | [standalone]

#246325

On Tue, Mar 15, 2022 at 08:28:41AM -0700, Cousin Stanley wrote:
>   I was under the impression that 
>   package information returned by ....
> 
>     apt-cache show some-package
> 
>   for packages that I have not installed
>   would not be downloaded onto my system
>   until I actually requested it.

You are mistaken.  All of the information given by apt-cache is retrieved
from the package metadata that is CACHED on your system already.  That's
the whole point of the command's name.

The files it uses are in /var/lib/apt/lists/ if you want to look at them.
On my system:

unicorn:~$ grep -A 10 'Package: hugo' /var/lib/apt/lists/ftp.us.debian.org_debian_dists_bullseye_main_binary-amd64_Packages
Package: hugo
Source: hugo (0.80.0-6)
Version: 0.80.0-6+b5
Installed-Size: 47774
Maintainer: Debian Go Packaging Team <team+pkg-go@tracker.debian.org>
Architecture: amd64
Depends: libsass1 (>= 3.6.3), libc6 (>= 2.4)
Recommends: git
Description: Fast and flexible Static Site Generator written in Go
Homepage: https://gohugo.io/
Built-Using: go-md2man-v2 (= 2.0.0+ds-5), golang-1.15 (= 1.15.9-6), golang-blackfriday (= 1.6.0-1), [...]

Yours may have a different filename, depending on which mirrors you use.

[toc] | [prev] | [next] | [standalone]

#246326

On Tue, Mar 15 2022 at 08:28:41 AM, Cousin Stanley <cousinstanley@gmail.com> wrote:
>
> <snip>
>
>   I was under the impression that 
>   package information returned by ....
>
>     apt-cache show some-package
>
>   for packages that I have not installed
>   would not be downloaded onto my system
>   until I actually requested it.
>
>   If that  is  the case then a transmission
>   would be happening when one made
>   such a request.
>
>   Does the Debian package manager
>   really download package information
>   for  all  ~59,000  avaiilabel packages 
>   in anticipation that users will need it 
>   at sometime in the future ?
>

Yes, this is what happens.  See the files in the /var/lib/apt/lists
directory.

>   That would be suprising to me.
>   

See the description of the update operation in the apt-get manpage.

> <snip>

-- 
regards,
kushal

[toc] | [prev] | [next] | [standalone]

#246327

On 2022-03-15, Cousin Stanley <cousinstanley@gmail.com> wrote:
>
>> Whether or not you want to see it
>> is a different issue. 
>
>   I understand this.
>
>> The data is already on your system, so
>> there's no transmission happening.
>
>   I do  not  understand this.
>
>   I was under the impression that 
>   package information returned by ....
>
>     apt-cache show some-package
>
>   for packages that I have not installed
>   would not be downloaded onto my system
>   until I actually requested it.

'apt update' downloads the package metadata; when if you give apt the
update flag you request exactly that.

[toc] | [prev] | [next] | [standalone]

#246328

Cousin Stanley wrote: 
> Cousin Stanley wrote :
> > The data is already on your system, so
> > there's no transmission happening.
> 
>   I do  not  understand this.
...

>   Does the Debian package manager
>   really download package information
>   for  all  ~59,000  avaiilabel packages 
>   in anticipation that users will need it 
>   at sometime in the future ?
> 
>   That would be suprising to me.

Now you are surprised, and informed.

apt update acquires all the information about all the packages
in the repositories you have configured, and stores that for
later use.

When you decide to install a package, apt figures out, all on
your own machine, what packages are necessary to make your
request work, then downloads those packages and installs them.

The packages are stored until you decide to delete them, by the
way, so you can reinstall them without further network costs.

apt list --upgradable doesn't incur a network transaction.

If you install apticron, or unattended-upgrades, or any of
several other services, you can have your system run apt updates
automatically. Some of them can then run package upgrades
automatically. Some of them can reboot your system automatically
when a kernel upgrade comes along.

If you have a flock of machines, one of them can download all
the updates for the others so that external network bandwidth is
preserved. This can be done on a proxy cache basis (packages are
retrieved on demand and held for further requests) or as a
complete local mirror of an apt repo.

-dsr-

[toc] | [prev] | [next] | [standalone]

#246336

On 3/15/22, Dan Ritter <dsr@randomstring.org> wrote:
> Cousin Stanley wrote:
>> Cousin Stanley wrote :
>> > The data is already on your system, so
>> > there's no transmission happening.
>>
>>   I do  not  understand this.
> ...
>
>>   Does the Debian package manager
>>   really download package information
>>   for  all  ~59,000  avaiilabel packages
>>   in anticipation that users will need it
>>   at sometime in the future ?
>>
>>   That would be suprising to me.
>
> Now you are surprised, and informed.


My linux-image-amd64 upgrade got mangled the other day so I was in
"man apt-get" and apt-cache looking for ways to coerce success (beyond
apt's recommended "dpkg --configure -a"). Found this and had intended
to eventually post here anyway:

apt-cache stats

Thought it might prove of interest for others, too, with respect to
seeing real numbers about the amazing volume of packages all
interacting together under Debian's hood. Concerning this thread, the
multi-megabyte sizes of the files under /var/lib/apt/lists reflect the
package numbers found via "apt-cache stats". I can still remember my
first ah-ha moment upon opening up one of those files and peeking in
out of curiosity years ago..

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#246364

On 3/15/22 19:20, Cindy Sue Causey wrote:

> apt-cache stats
> 
> Thought it might prove of interest for others, too, with respect to
> seeing real numbers about the amazing volume of packages all
> interacting together under Debian's hood.

   Thanks ....

   I was not aware of this apt-cache option
   and it does seem useful to me.


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [prev] | [next] | [standalone]

#246323

[Multipart message — attachments visible in raw view] — view raw

On Tue, Mar 15, 2022 at 06:36:52AM -0700, Cousin Stanley wrote:
> tomas@tuxteam.de wrote:
> 
> > No, it seems you haven't understood.
> > ....
> 
>   I assure you that I do understand the need 
>   for access to the Built-Using list. 
> 
>   What I don't understand is the necessity
>   to transmit a string of 3933 bytes
>   for 87 golang packages [...]

You conveniently snipped out my attempt at explaining that. As a
sysadmin I sure want to see that info. We all got by now that you
don't. Now selecting a default in this situation can go in this
or that direction.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#246316

Cousin Stanley wrote:
>   Reading this newsgroup earlier today
>   someone mentioned the  hugo  package
>   for static site generation.
>
>   I was curious about the package
>   so I tried .... 
>
>     $ apt-cache show hugo

  ...

  i have been building hugo on my Debian system for
quite a while now.

  grab the whole repository and build it.  it will
be more up to date.

1. git clone <url>:

2. cd hugo

3. go install -tags extended

  i need the extended version but if you don't you can leave that
option off.

  the hugo binary ends up in $HOME/go/bin

  if you need a specific version you can check it out before
building.

  all those golang packages are then not needed.  just the base
ones are installed.


ii  golang-1.17-doc                      1.17.8-1                           all          Go programming language - documentation
ii  golang-1.17-go                       1.17.8-1                           amd64        Go programming language compiler, linker, compiled stdlib
ii  golang-1.17-src                      1.17.8-1                           all          Go programming language - source files
ii  golang-go:amd64                      2:1.17~1                           amd64        Go programming language compiler, linker, compiled stdlib
ii  golang-src                           2:1.17~1                           all          Go programming language - source files


  songbird

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web