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

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

An introduction to Debian's topology/structure/???

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

Contents

  An introduction to Debian's topology/structure/??? Richard Owlett <rowlett@cloud85.net> - 2018-07-18 15:50 +0200
    Re: An introduction to Debian's topology/structure/??? Michael Stone <mstone@debian.org> - 2018-07-18 16:10 +0200
      Re: An introduction to Debian's topology/structure/??? Richard Owlett <rowlett@cloud85.net> - 2018-07-19 13:40 +0200
        Re: An introduction to Debian's topology/structure/??? Jochen Spieker <ml@well-adjusted.de> - 2018-07-19 15:40 +0200
          Re: An introduction to Debian's topology/structure/??? Richard Owlett <rowlett@cloud85.net> - 2018-07-19 16:30 +0200
          Re: An introduction to Debian's topology/structure/??? Brian <ad44@cityscape.co.uk> - 2018-07-20 01:50 +0200
            Re: An introduction to Debian's topology/structure/??? Richard Owlett <rowlett@cloud85.net> - 2018-07-20 12:40 +0200
        Re: An introduction to Debian's topology/structure/??? David Wright <deblis@lionunicorn.co.uk> - 2018-07-19 17:20 +0200
          Re: An introduction to Debian's topology/structure/??? Henrique de Moraes Holschuh <hmh@debian.org> - 2018-07-19 17:50 +0200
            Re: An introduction to Debian's topology/structure/??? Richard Owlett <rowlett@cloud85.net> - 2018-07-20 14:10 +0200
              Re: An introduction to Debian's topology/structure/??? David Wright <deblis@lionunicorn.co.uk> - 2018-07-20 23:10 +0200
                Re: An introduction to Debian's topology/structure/??? Richard Owlett <rowlett@cloud85.net> - 2018-07-21 17:50 +0200
          Re: An introduction to Debian's topology/structure/??? Richard Owlett <rowlett@cloud85.net> - 2018-07-19 18:40 +0200

#197766 — An introduction to Debian's topology/structure/???

"Topology" may be a poor word choice.

First I'm looking comparison of required, important, standard, optional, 
and extra as package labels [particularly interested in corner cases]. 
I've been looking at [https://www.debian.org/doc/debian-policy/]. I'm 
not grasping something. Not sure what ;/

Similarly for Depends, Recommends, Suggests, etc. I'm currently reading
[https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_package_dependencies]
Other suggestions?

TIA

[toc] | [next] | [standalone]

#197768

On Wed, Jul 18, 2018 at 08:44:13AM -0500, Richard Owlett wrote:
>First I'm looking comparison of required, important, standard, 
>optional, and extra as package labels [particularly interested in 
>corner cases]. I've been looking at 
>[https://www.debian.org/doc/debian-policy/]. I'm not grasping 
>something. Not sure what ;/

Well, it's hard to answer questions when you don't ask a question. For 
the most part the priorities don't matter much, and are largely a 
historical curiosity. Extra is gone, standard and important don't mean 
much. So most packages are optional, and a few that should be really 
hard to remove are required. Being required has the possible advantage 
that other packages don't need to explicitly list dependencies on the 
required package (but in practice you usually end up with a versioned 
libc6 dependency anyway). It does save a bit on the overhead of every 
single package having dependencies on /bin/sh and coreutils that the 
dependency resolver would then have to consider.

Mike Stone

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

#197791

On 07/18/2018 09:06 AM, Michael Stone wrote:
> On Wed, Jul 18, 2018 at 08:44:13AM -0500, Richard Owlett wrote:
>> First I'm looking comparison of required, important, standard, 
>> optional, and extra as package labels [particularly interested in 
>> corner cases]. I've been looking at 
>> [https://www.debian.org/doc/debian-policy/]. I'm not grasping 
>> something. Not sure what ;/
> 
> Well, it's hard to answer questions when you don't ask a question. For 
> the most part the priorities don't matter much, and are largely a 
> historical curiosity. Extra is gone, standard and important don't mean 
> much. So most packages are optional, and a few that should be really 
> hard to remove are required. Being required has the possible advantage 
> that other packages don't need to explicitly list dependencies on the 
> required package (but in practice you usually end up with a versioned 
> libc6 dependency anyway). It does save a bit on the overhead of every 
> single package having dependencies on /bin/sh and coreutils that the 
> dependency resolver would then have to consider.
> 

I was, I thought, asking for explicit distinctions between adjacent 
priorities. Your reply was that the distinctions were no longer germane. 
That, effectively there are now only two, required and optional.

That changes the landscape surrounding a personal project. Which some 
might describe as an extremely minimalist Debian. I would rather 
describe it as a "proper subset" of Debian for a particular use. That is 
why, in another thread, I ask about "Debian from Scratch".

That leads to asking two related questions:
  1. How can I get a list of packages tagged as required?
  2. What section of the installer installs packages tagged as required?
     I assume the answer will, in part, be a referral to some developer
     oriented documentation. [My motivation is personal education rather
     that creating the next "killer app].

I will then investigate which of my optional packages already have an 
explicit dependence on a "required" app. That will allow me to enumerate 
which "required" packages *may* actually be unnecessary.

Thank you.

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

#197797

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

Richard Owlett:
> 
> That leads to asking two related questions:
>  1. How can I get a list of packages tagged as required?

Aptitude is great for answering questions like this:

$ aptitude search '?priority(required) ?archive(stable)'

https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html

>  2. What section of the installer installs packages tagged as required?
>     I assume the answer will, in part, be a referral to some developer
>     oriented documentation. [My motivation is personal education rather
>     that creating the next "killer app].

You may want to ask this question in debian-boot (surprisingly, this
list appears to be the place to discuss d-i).

J.
-- 
I often play sports / do exercise.
[Agree]   [Disagree]
                 <http://archive.slowlydownward.com/NODATA/data_enter2.html>

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

#197799

On 07/19/2018 08:34 AM, Jochen Spieker wrote:
> Richard Owlett:
>>
>> That leads to asking two related questions:
>>   1. How can I get a list of packages tagged as required?
> 
> Aptitude is great for answering questions like this:
> 
> $ aptitude search '?priority(required) ?archive(stable)'

Exactly what I needed ;}
As I suspected, there are many packages which are there because 
"everyone" needs &/or expects them. But I'm a particular unique 
individual with peculiar goals.

> 
> https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html

I wasn't aware of that manual. But that is exactly what I need for this 
and other issues,

> 
>>   2. What section of the installer installs packages tagged as required?
>>      I assume the answer will, in part, be a referral to some developer
>>      oriented documentation. [My motivation is personal education rather
>>      that creating the next "killer app].
> 
> You may want to ask this question in debian-boot (surprisingly, this
> list appears to be the place to discuss d-i).

Thank you.

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

#197817

On Thu 19 Jul 2018 at 15:34:04 +0200, Jochen Spieker wrote:

> Richard Owlett:
> > 
> > That leads to asking two related questions:

[...]

 
> >  2. What section of the installer installs packages tagged as required?
> >     I assume the answer will, in part, be a referral to some developer
> >     oriented documentation. [My motivation is personal education rather
> >     that creating the next "killer app].
> 
> You may want to ask this question in debian-boot (surprisingly, this
> list appears to be the place to discuss d-i).

Can it be answered here? The base system. (The OP is familiar with
debootstrap).

-- 
Brian.

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

#197826

On 07/19/2018 06:41 PM, Brian wrote:
> On Thu 19 Jul 2018 at 15:34:04 +0200, Jochen Spieker wrote:
> [snip]
>>
>> You may want to ask this question in debian-boot (surprisingly, this
>> list appears to be the place to discuss d-i).
> 
> Can it be answered here? The base system. (The OP is familiar with
> debootstrap).
> 

*ROFL*
Yes, I've attempted to use it.
*NEVER* successfully.
All the documentation/HOWTO's assumed knowledge/experience not in evidence.
I gave up.

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

#197800

On Thu 19 Jul 2018 at 06:38:08 (-0500), Richard Owlett wrote:
> On 07/18/2018 09:06 AM, Michael Stone wrote:
> >On Wed, Jul 18, 2018 at 08:44:13AM -0500, Richard Owlett wrote:
> >>First I'm looking comparison of required, important, standard,
> >>optional, and extra as package labels [particularly interested
> >>in corner cases]. I've been looking at
> >>[https://www.debian.org/doc/debian-policy/]. I'm not grasping
> >>something. Not sure what ;/
> >
> >Well, it's hard to answer questions when you don't ask a question.
> >For the most part the priorities don't matter much, and are
> >largely a historical curiosity. Extra is gone, standard and
> >important don't mean much. So most packages are optional, and a
> >few that should be really hard to remove are required. Being
> >required has the possible advantage that other packages don't need
> >to explicitly list dependencies on the required package (but in
> >practice you usually end up with a versioned libc6 dependency
> >anyway). It does save a bit on the overhead of every single
> >package having dependencies on /bin/sh and coreutils that the
> >dependency resolver would then have to consider.
> >
> 
> I was, I thought, asking for explicit distinctions between adjacent
> priorities. Your reply was that the distinctions were no longer
> germane. That, effectively there are now only two, required and
> optional.
> 
> That changes the landscape surrounding a personal project. Which
> some might describe as an extremely minimalist Debian. I would
> rather describe it as a "proper subset" of Debian for a particular
> use. That is why, in another thread, I ask about "Debian from
> Scratch".
> 
> That leads to asking two related questions:
>  1. How can I get a list of packages tagged as required?
>  2. What section of the installer installs packages tagged as required?
>     I assume the answer will, in part, be a referral to some developer
>     oriented documentation. [My motivation is personal education rather
>     that creating the next "killer app].
> 
> I will then investigate which of my optional packages already have
> an explicit dependence on a "required" app. That will allow me to
> enumerate which "required" packages *may* actually be unnecessary.

While there are commands like   aptitude search   and   aptitude why
available for such purposes, these are really designed for routine
maintenance. For your purposes, I think you need to develop a more
intimate relationship with the files in /var/lib/apt/lists/,
particularly ftp.us.debian.org_debian_dists_stretch_main_binary-amd64_Packages
(which may be named differently on your system). There's a similar
file /var/lib/dpkg/status which contains a subset of this information
for any packages with status on your system (usually "installed").

You can make many investigations (en masse) using OR'd grep
expressions on these files, but for more in-depth investigations,
it's worth parsing it into, say, a python dictionary of fields
containing lists of items in each field.

So, for example, I have a program which, for each package, gives
a list of packages that Depends (± Recommends ± Suggests) on it.
By filtering input to that program by the Priority of packages,
and by Recommends/Suggests/¬Depends, it's trivial to answer your
question about which packages are not required on your system,
either through "Priority: required" or a Depends. Working on the raw
data yourself might make it easier to study your corner cases that
using the potted tools that most people suggest.

Cheers,
David.

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

#197801

On Thu, 19 Jul 2018, David Wright wrote:
> While there are commands like   aptitude search   and   aptitude why
> available for such purposes, these are really designed for routine
> maintenance. For your purposes, I think you need to develop a more
> intimate relationship with the files in /var/lib/apt/lists/,

or look at the utilities that the package dctrl-tools provides ;-)

-- 
  Henrique Holschuh

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

#197827

On 07/19/2018 10:46 AM, Henrique de Moraes Holschuh wrote:
> On Thu, 19 Jul 2018, David Wright wrote:
>> While there are commands like   aptitude search   and   aptitude why
>> available for such purposes, these are really designed for routine
>> maintenance. For your purposes, I think you need to develop a more
>> intimate relationship with the files in /var/lib/apt/lists/,
> 
> or look at the utilities that the package dctrl-tools provides ;-)
> 

For my fellow newbies who come across this thread, the associated man 
pages are:

https://manpages.debian.org/stretch/dctrl-tools/grep-dctrl.1.en.html
   grep-dctrl, grep-status, grep-available, grep-aptavail, grep-debtags
https://manpages.debian.org/stretch/dctrl-tools/sort-dctrl.1.en.html
https://manpages.debian.org/stretch/dctrl-tools/tbl-dctrl.1.en.html
   generate tabular representations of data in dctrl format
https://manpages.debian.org/stretch/dctrl-tools/sync-available.8.en.html
   sync dpkg's available database with apt's database

GREP-DCTRL(1) says in part, "Use your imagination! The building blocks 
are there ..."

I believe it ;/ I suspect piping its output to tbl-dctrl will be 
interesting to say the least.

Thanks.

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

#197829

On Fri 20 Jul 2018 at 07:07:34 (-0500), Richard Owlett wrote:
> On 07/19/2018 10:46 AM, Henrique de Moraes Holschuh wrote:
> >On Thu, 19 Jul 2018, David Wright wrote:
> >>While there are commands like   aptitude search   and   aptitude why
> >>available for such purposes, these are really designed for routine
> >>maintenance. For your purposes, I think you need to develop a more
> >>intimate relationship with the files in /var/lib/apt/lists/,
> >
> >or look at the utilities that the package dctrl-tools provides ;-)
> >
> 
> For my fellow newbies who come across this thread, the associated
> man pages are:
> 
> https://manpages.debian.org/stretch/dctrl-tools/grep-dctrl.1.en.html
>   grep-dctrl, grep-status, grep-available, grep-aptavail, grep-debtags
> https://manpages.debian.org/stretch/dctrl-tools/sort-dctrl.1.en.html
> https://manpages.debian.org/stretch/dctrl-tools/tbl-dctrl.1.en.html
>   generate tabular representations of data in dctrl format
> https://manpages.debian.org/stretch/dctrl-tools/sync-available.8.en.html
>   sync dpkg's available database with apt's database
> 
> GREP-DCTRL(1) says in part, "Use your imagination! The building
> blocks are there ..."
> 
> I believe it ;/ I suspect piping its output to tbl-dctrl will be
> interesting to say the least.

I'm not sure what tabulating it adds over a plain listing, unless
you intend it for documentation or publication.

But anyway, I found that defining a specific solution with
commands like these, combinations of commandline options etc.
was more difficult than a few lines of python once I had a
framework program that parsed the Debian control files into
suitable dictionaries.

Of course, this methodology is unsuitable for general release
unlike Debian's tools. But the skills one learns doing the work
onesself with shell and a programming language will be more
transferable to situations where Debian doesn't have a ready-built
tool. (eg the programs I use for smart editing of files en masse.)

BTW I'm slightly surprised you self-describe as a newbie.
You've been plugging away at Debian for years now and have
been reading voraciously in retirement.

Cheers,
David.

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

#197849

On 07/20/2018 04:06 PM, David Wright wrote:
> On Fri 20 Jul 2018 at 07:07:34 (-0500), Richard Owlett wrote:
>> [snip]
>>
>> GREP-DCTRL(1) says in part, "Use your imagination! The building
>> blocks are there ..."
>>
>> I believe it ;/ I suspect piping its output to tbl-dctrl will be
>> interesting to say the least.
> 
> I'm not sure what tabulating it adds over a plain listing, unless
> you intend it for documentation or publication.

It is how I grasp data.
I.E. a spreadsheet vs VS Encyclopedia ;/

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

#197803

On 07/19/2018 10:13 AM, David Wright wrote:
> On Thu 19 Jul 2018 at 06:38:08 (-0500), Richard Owlett wrote:
>> On 07/18/2018 09:06 AM, Michael Stone wrote:
>>> On Wed, Jul 18, 2018 at 08:44:13AM -0500, Richard Owlett wrote:
>>>> First I'm looking comparison of required, important, standard,
>>>> optional, and extra as package labels [particularly interested
>>>> in corner cases]. I've been looking at
>>>> [https://www.debian.org/doc/debian-policy/]. I'm not grasping
>>>> something. Not sure what ;/
>>>
>>> Well, it's hard to answer questions when you don't ask a question.
>>> For the most part the priorities don't matter much, and are
>>> largely a historical curiosity. Extra is gone, standard and
>>> important don't mean much. So most packages are optional, and a
>>> few that should be really hard to remove are required. Being
>>> required has the possible advantage that other packages don't need
>>> to explicitly list dependencies on the required package (but in
>>> practice you usually end up with a versioned libc6 dependency
>>> anyway). It does save a bit on the overhead of every single
>>> package having dependencies on /bin/sh and coreutils that the
>>> dependency resolver would then have to consider.
>>>
>>
>> I was, I thought, asking for explicit distinctions between adjacent
>> priorities. Your reply was that the distinctions were no longer
>> germane. That, effectively there are now only two, required and
>> optional.
>>
>> That changes the landscape surrounding a personal project. Which
>> some might describe as an extremely minimalist Debian. I would
>> rather describe it as a "proper subset" of Debian for a particular
>> use. That is why, in another thread, I ask about "Debian from
>> Scratch".
>>
>> That leads to asking two related questions:
>>   1. How can I get a list of packages tagged as required?
>>   2. What section of the installer installs packages tagged as required?
>>      I assume the answer will, in part, be a referral to some developer
>>      oriented documentation. [My motivation is personal education rather
>>      that creating the next "killer app].
>>
>> I will then investigate which of my optional packages already have
>> an explicit dependence on a "required" app. That will allow me to
>> enumerate which "required" packages *may* actually be unnecessary.
> 
> While there are commands like   aptitude search   and   aptitude why
> available for such purposes, these are really designed for routine
> maintenance. For your purposes, I think you need to develop a more
> intimate relationship with the files in /var/lib/apt/lists/,
> particularly

> ftp.us.debian.org_debian_dists_stretch_main_binary-amd64_Packages

I suspect a typo. Clicked on it and got "Address Not Found".
Will search later.

> (which may be named differently on your system). There's a similar
> file /var/lib/dpkg/status which contains a subset of this information
> for any packages with status on your system (usually "installed").

I did a quick browse of /var/lib/apt/ and /var/lib/dpkg/ directories.
I suspect there are answers there to questions I haven't thought of ;/

> 
> You can make many investigations (en masse) using OR'd grep
> expressions on these files, but for more in-depth investigations,
> it's worth parsing it into, say, a python dictionary of fields
> containing lists of items in each field.

I had been thinking of something similar in Tcl/Tk (which I'm learning) 
rather than python (which I've not had cause to investigate).

> 
> So, for example, I have a program which, for each package, gives
> a list of packages that Depends (± Recommends ± Suggests) on it.
> By filtering input to that program by the Priority of packages,
> and by Recommends/Suggests/¬Depends, it's trivial to answer your
> question about which packages are not required on your system,
> either through "Priority: required" or a Depends. Working on the raw
> data yourself might make it easier to study your corner cases that
> using the potted tools that most people suggest. >
> Cheers,
> David.

Thank you.

[toc] | [prev] | [standalone]

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

csiph-web