Exploring package interrelationships

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Exploring package interrelationships

Richard Owlett-3
Long term goal: *personal* definition of a minimalist Debian

current goal: grok how packages interact

current *test case*/example: a very minimal install of MATE
An illustration of the opposite of what I want is task-mate-desktop.
It's description states:
> This task package is used to install the Debian desktop, featuring
> the MATE desktop environment, and with other packages that Debian
> users expect to have available on the desktop.In what I want only the top level menu headings [Applications Places
System] would exist. Under Applications the sub-headings [Accessories
Education Graphics etc] may exist but their contents would be empty.

proposed procedure:
Do a minimal install of a CLI system.
Follow with "apt-get install" of a very minimal set of MATE components.
[Pluma, Caja, and Synaptic would be included]

Under "https://packages.debian.org/stretch/" I have been exploring
entries under task-mate-desktop, mate-desktop-environment,
mate-desktop-environment-core, and desktop-base.

I'm do getting a good visualization of how to reach my goal. Something
that acted on repositories as apt-cache does on the current machine's
cache would be useful.

In past conversations it has been suggested that I do a typical install
and just un-install the un-desired elements:

That is undesirable for two primary reasons:
1. I would not reach my primary goal of "grok how packages interact".
2. Uncertainty of what the resulting "thing" would be.
    [While channel surfing recently, I caught a visual example. A
     children's show was exploring mixing and sorting. The 1st example
     was putting colored balls in a glass bowl. There was no problem
     separating the balls into 2 sets. The 2nd example was mixing two
     glasses of water with red dye in one and green in the other. The
     mixing could not be undone.]

Comments/suggestions/readings/search terms.

TIA




Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

Nicholas Geovanis-2
On Sun, Apr 14, 2019 at 7:33 AM Richard Owlett <[hidden email]> wrote:

That is undesirable for two primary reasons:
1. I would not reach my primary goal of "grok how packages interact".

I think a better way to proceed, which will be quite confusing itself :-) is to
simply explore those relationships using the tools that there are. Rather than
exploring it less-systematically under trial by fire. If you want to experiment live
while exploring, fire up a VM at the same time.

2. Uncertainty of what the resulting "thing" would be.

This shouldn't be an issue IMO. Why is that important?
It's a Debian system with certain packages installed. If you work
in a data center and manage hundreds or thousands of servers,
for example, your config management software cares. You don't.
But I see no reason to care or stress on this in any context.
 
Comments/suggestions/readings/search terms.

TIA




Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

Richard Owlett-3
On 04/14/2019 07:50 AM, Nicholas Geovanis wrote:
> On Sun, Apr 14, 2019 at 7:33 AM Richard Owlett <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     That ...

Moderate trimming is good.  Yours destroyed the context of "That".
It referred to:
>>> In past conversations it has been suggested that I do a typical
>>> install and just un-install the un-desired elements:

>> That is undesirable for two primary reasons:
>>     1. I would not reach my primary goal of "grok how packages interact".
>
>
> I think a better way to proceed, which will be quite confusing itself
> :-) is to
> simply explore those relationships using the tools that there are.

What tools are you referring to?

> Rather than
> exploring it less-systematically under trial by fire. If you want to
> experiment live
> while exploring, fire up a VM at the same time.
>
>     2. Uncertainty of what the resulting "thing" would be.
>
>
> This shouldn't be an issue IMO. Why is that important?

I've been down this route before. It gave an unsatisfactory
approximation of what was desired. I was explicitly specifying an
defective approach that I am not interested in following.
YMMV ;/

> It's a Debian system with certain packages installed. If you work
> in a data center and manage hundreds or thousands of servers,
> for example, your config management software cares. You don't.
> But I see no reason to care or stress on this in any context.
>
>     Comments/suggestions/readings/search terms.
>
>     TIA



Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

David Wright-3
In reply to this post by Richard Owlett-3
On Sun 14 Apr 2019 at 07:32:36 (-0500), Richard Owlett wrote:
> Long term goal: *personal* definition of a minimalist Debian

Debian is in no way minimilist: in fact, it's the opposite,
"The universal operating system" claiming over 51000 packages.

You're the one claiming to be a minimalist, though we may have our
doubts because your "minimal CLI" system is to include tools like
synaptic which requires a graphical system of one kind or another.

But by having a *personal* definition (your emphasis) of what's
minimalist^H^H^H, you've reserved the role of judge and jury on
any suggestions made here. As usual.

> current goal: grok how packages interact

AIUI, which is but partially, the interactions at the granularity
of installation (ie ignoring library calls and suchlike) are
encapsulated in the Packages file's {Pre-,}Depends: lines.

I've taken a look at these using Python dictionaries, but it would
appear that they actually form a type of directed graph, for which
mathematicians have a battery of tools, I'm sure. (It's not merely
"simple" because two packages can depend on each other, but I haven't
looked for loops or other complications.)

> current *test case*/example: a very minimal install of MATE
> An illustration of the opposite of what I want is task-mate-desktop.
> It's description states:
> > This task package is used to install the Debian desktop, featuring
> > the MATE desktop environment, and with other packages that Debian
> > users expect to have available on the desktop.In what I want only
> > the top level menu headings [Applications Places
> System] would exist. Under Applications the sub-headings [Accessories
> Education Graphics etc] may exist but their contents would be empty.
>
> proposed procedure:
> Do a minimal install of a CLI system.
> Follow with "apt-get install" of a very minimal set of MATE components.
> [Pluma, Caja, and Synaptic would be included]
>
> Under "https://packages.debian.org/stretch/" I have been exploring
> entries under task-mate-desktop, mate-desktop-environment,
> mate-desktop-environment-core, and desktop-base.
>
> I'm do getting a good visualization of how to reach my goal. Something
> that acted on repositories as apt-cache does on the current machine's
> cache would be useful.

Well, there's your answer then. Study how it works. Download the
source and analyse it.

> In past conversations it has been suggested that I do a typical
> install and just un-install the un-desired elements:
>
> That is undesirable for two primary reasons:
> 1. I would not reach my primary goal of "grok how packages interact".
> 2. Uncertainty of what the resulting "thing" would be.
>    [While channel surfing recently, I caught a visual example. A
>     children's show was exploring mixing and sorting. The 1st example
>     was putting colored balls in a glass bowl. There was no problem
>     separating the balls into 2 sets. The 2nd example was mixing two
>     glasses of water with red dye in one and green in the other. The
>     mixing could not be undone.]

I don't understand. You're implying that the install-then-uninstall
method will mix packages like dye in water, and I've seen no evidence
that Debian systems behave like that (though I can't speak for synaptic).

> Comments/suggestions/readings/search terms.

You've answered it here: it's in the package resolvers. At this stage
you might be expected to have an idea of how many distinct resolvers
there are in Debian's various installers, apt-get, aptitude, dselect,
etc. Myself—I don't. I've always found apt-get's satisfactory enough
without investigating further.

Cheers,
David.

Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

bw-2
In reply to this post by Richard Owlett-3
In-Reply-To: <[hidden email]>

<snip>
>An illustration of the opposite of what I want is task-mate-desktop.
<snip>
>In what I want only the top level menu headings [Applications Places
>System] would exist. Under Applications the sub-headings [Accessories
>Education Graphics etc] may exist but their contents would be empty.

I don't think your proposed procedure would get you a menu setup like you
say you want.

>proposed procedure:
>Do a minimal install of a CLI system.
>Follow with "apt-get install" of a very minimal set of MATE components.
>[Pluma, Caja, and Synaptic would be included]

See, by installing these mate components you will also pull in some things
that will be listed in sub-menus you said should be empty.  The easiest
way IME to find out what pulls in a pkg with a doodad that has a menu item
is to install them one at a time and check the menu.  If you can't live
with those dependencies, then immediately uninstall it and use
autoremove with apt.  You are using apt, right?

>In past conversations it has been suggested that I do a typical install
>and just un-install the un-desired elements:
>
>
>That is undesirable for two primary reasons:
>1. I would not reach my primary goal of "grok how packages interact".

It might help your understanding though.  I would try it that way, do a
full install, then a full install without recommends, and observe what
does and does not work the way you expect.  Don't forget the recommends
when building your minimal system also.  Many programs work fine without
them, but some lose major functionality... you don't know until you try.

Nobody can make the decisions because you're the one with the need and
desire to grok the thing.  It's good, try it all out, break a few systems
trying to do things you shouldn't.  It can really be an eye-opener how
complicated pkg management is.

In the end, I think metapkgs with selective removal are best for the
desktop environments though.  The way you want to do it is great for
window manager setup...

Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

tomas@tuxteam.de
In reply to this post by Richard Owlett-3
On Sun, Apr 14, 2019 at 08:38:48AM -0500, Richard Owlett wrote:

[...]

> >>>In past conversations it has been suggested that I do a typical
> >>>install and just un-install the un-desired elements:

Start with what debootstrap [1] gives you and work up from there.
This is what any regular Debian installer does to get itself started.
That's what I do when trying to get a minimal install.

But beware: debootstrap is perhaps more minimal than what you might
consider minimal. No GUI. Not even an SSH daemon. But apt.

Debootstrap is a harsh mistress (yeah, stolen from somewhere). But
you might end up liking it once you get the hang of it...

Cheers

[1] Apart from having (of course) its extensive manual page,
  it has an entry in the Debian wiki:
  https://wiki.debian.org/Debootstrap

-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

Peter Wiersig
In reply to this post by Richard Owlett-3
Richard Owlett <[hidden email]> writes:
> Long term goal: *personal* definition of a minimalist Debian
>
> current goal: grok how packages interact

http://www.macfreek.nl/memory/Dependency_Graph_Debian_Packages
TLDR:
$ apt-cache dotty mate-desktop > dependency-graph.dot
$ dot -Tpng  dependency-graph.dot

That either creates files named after the input or at least shows a
graphic of the package you specified.

I think I remember and older planet.debian.org post where someone else
had done similar.  Have not found it in a very short research session.


Alternatively explore interactive with aptitude when you disable the
solver there and pick the resulting installation by hand, and decide
which suggest/recommend you follow, and which non-essential package you
might even not install.

Peter

Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

Richard Owlett-3
In reply to this post by tomas@tuxteam.de
On 04/15/2019 02:12 AM, [hidden email] wrote:

> On Sun, Apr 14, 2019 at 08:38:48AM -0500, Richard Owlett wrote:
>
> [...]
>
>>>>> In past conversations it has been suggested that I do a typical
>>>>> install and just un-install the un-desired elements:
>
> Start with what debootstrap [1] gives you and work up from there.
> This is what any regular Debian installer does to get itself started.
> That's what I do when trying to get a minimal install.

Brings back memories. I had tried to do something similar years ago when
I first got started with Linux. I didn't have enough background and got
thoroughly *lost*. THANKS for the reminder. IIRC Multistrap may match my
mindset better. I've a lot of re-reading to do (jessie was current last
time ;)

>
> But beware: debootstrap is perhaps more minimal than what you might
> consider minimal. No GUI. Not even an SSH daemon. But apt.

ROFL I once said there was no need for floppies larger than 1.44M - does
that date me?

>
> Debootstrap is a harsh mistress (yeah, stolen from somewhere). But
> you might end up liking it once you get the hang of it...

I liked it bu NEVER did get the hang of it ;)


>
> [1] Apart from having (of course) its extensive manual page,
>    it has an entry in the Debian wiki:
>    https://wiki.debian.org/Debootstrap
>
> -- t
>


Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

Cindy Sue Causey
In reply to this post by tomas@tuxteam.de
On 4/15/19, [hidden email] <[hidden email]> wrote:
>
> Debootstrap is a harsh mistress (yeah, stolen from somewhere). But
> you might end up liking it once you get the hang of it...


Don't know if I ever heard that, at least not that I can remember that
topic specifically. I just know that debootstrap always *WORKS FOR
ME*.

Well, *IT WORKS* except for that one time that root kept yelling, "I
HAVE NO NAME!" That eventually turned out to be caused by symlinking
/debootstrap-directory/var/cache/apt/archives to an offline dotDEB
file hoard. Accidentally discovered that using "mount -B" instead of
"ln -s" solved root's identity crisis.

I've been "bored" lately and so was going to spend some time nosing
around to see if any other methods are dialup friendly. What you
said... I'll have to poke around at that, too. Something in the very
back of my head is nagging that I may have read some disgruntled
chatter LONG before it ever made enough sense to find a more permanent
spot toward the front of the class where its topic would remain more..
[conscionable]. :)

Cindy :)
--
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

Richard Owlett-3
In reply to this post by Peter Wiersig
On 04/15/2019 03:39 AM, Peter Wiersig wrote:
> Richard Owlett <[hidden email]> writes:
>> Long term goal: *personal* definition of a minimalist Debian
>>
>> current goal: grok how packages interact
>
> http://www.macfreek.nl/memory/Dependency_Graph_Debian_Packages
> TLDR:
> $ apt-cache dotty mate-desktop > dependency-graph.dot
> $ dot -Tpng  dependency-graph.dot


After I posted I found a reference using Graphiz with "apt-cache dotty"
I haven't read the documentation yet.

I tried you example and got a command not found at second line.
I found a man page for "dot" then went looking for a package to provide
it -- found/installed xdot.

Using "dot -Tps  dependency-graph.dot > owl.ps" I got a displayable, if
not readable, graph. There was a warning in what I had read about
"dotty" about viewablity issues if the graph was too complex. Suspect
that is problem.



>
> That either creates files named after the input or at least shows a
> graphic of the package you specified.
>
> I think I remember and older planet.debian.org post where someone else
> had done similar.  Have not found it in a very short research session.
>
>
> Alternatively explore interactive with aptitude when you disable the
> solver there and pick the resulting installation by hand, and decide
> which suggest/recommend you follow, and which non-essential package you
> might even not install.

I can't parse that sentence. By context I suspect I can do some
searching which will clarify.

>
> Peter
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

Gene Heskett-4
In reply to this post by Cindy Sue Causey
On Monday 15 April 2019 09:28:12 Cindy Sue Causey wrote:

> On 4/15/19, [hidden email] <[hidden email]> wrote:
> > Debootstrap is a harsh mistress (yeah, stolen from somewhere). But
> > you might end up liking it once you get the hang of it...
>
Somewhat off topic, but your reading material in your formative years
Cindy, is sadly lacking in familiarity with the output of one of the
last century's most prolific  Sci Fi authors named Robert A. Heinlein.
Specifically his treatise on living on or "in" the moon.  Go to your
public library and check out "The moon is a harsh mistress" and remedy
that lack. ;-)  I think you'll go back and get some more of his output.

> Don't know if I ever heard that, at least not that I can remember that
> topic specifically. I just know that debootstrap always *WORKS FOR
> ME*.
>
> Well, *IT WORKS* except for that one time that root kept yelling, "I
> HAVE NO NAME!" That eventually turned out to be caused by symlinking
> /debootstrap-directory/var/cache/apt/archives to an offline dotDEB
> file hoard. Accidentally discovered that using "mount -B" instead of
> "ln -s" solved root's identity crisis.
>
> I've been "bored" lately and so was going to spend some time nosing
> around to see if any other methods are dialup friendly. What you
> said... I'll have to poke around at that, too. Something in the very
> back of my head is nagging that I may have read some disgruntled
> chatter LONG before it ever made enough sense to find a more permanent
> spot toward the front of the class where its topic would remain more..
> [conscionable]. :)
>
> Cindy :)

I had forgotten there was still diakup country Cindy, my sympathies. But
with Pi at the FCC, its not going to be fixed on his watch, he is in big
telecom's pocket. "A Republic, Mam, if we can keep it", but we've not
been doing that good a job.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

David Wright-3
In reply to this post by Richard Owlett-3
On Mon 15 Apr 2019 at 08:50:12 (-0500), Richard Owlett wrote:

> On 04/15/2019 03:39 AM, Peter Wiersig wrote:
> > Richard Owlett <[hidden email]> writes:
> > > Long term goal: *personal* definition of a minimalist Debian
> > >
> > > current goal: grok how packages interact
> >
> > http://www.macfreek.nl/memory/Dependency_Graph_Debian_Packages
> > TLDR:
> > $ apt-cache dotty mate-desktop > dependency-graph.dot
> > $ dot -Tpng  dependency-graph.dot
>
> After I posted I found a reference using Graphiz with "apt-cache dotty"
> I haven't read the documentation yet.
>
> I tried you example and got a command not found at second line.
> I found a man page for "dot" then went looking for a package to
> provide it -- found/installed xdot.

I'm not sure we need the blow by blow account.

> Using "dot -Tps  dependency-graph.dot > owl.ps" I got a displayable,
> if not readable, graph. There was a warning in what I had read about
> "dotty" about viewablity issues if the graph was too complex. Suspect
> that is problem.

Add   -o APT::Cache::GivenOnly=1   to the commandline, and you'll get
a much smaller graph. I haven't figured out why python and
python-requests are missng from the graph, or is this a stretch/buster
difference. (I'm comparing the graph with the Packages entry:

Package: mate-desktop
Version: 1.16.2-2
Architecture: amd64
Replaces: mate-desktop-gnome
Depends: hicolor-icon-theme, libmate-desktop-2-17 (>= 1.10.0),
 mate-desktop-common (= 1.16.2-2), python, python-requests, libatk1.0-0
 (>= 1.12.4), libc6 (>= 2.4), libcairo-gobject2 (>= 1.10.0), libcairo2
 (>= 1.2.4), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.28.0),
 libgtk-3-0 (>= 3.0.0), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0
 (>= 1.14.0), libstartup-notification0 (>= 0.2), libxrandr2
Recommends: mate-user-guide
Breaks: mate-desktop-gnome

[edited].)

> > That either creates files named after the input or at least shows a
> > graphic of the package you specified.
> >
> > I think I remember and older planet.debian.org post where someone else
> > had done similar.  Have not found it in a very short research session.
> >
> >
> > Alternatively explore interactive with aptitude when you disable the
> > solver there and pick the resulting installation by hand, and decide
> > which suggest/recommend you follow, and which non-essential package you
> > might even not install.
>
> I can't parse that sentence. By context I suspect I can do some
> searching which will clarify.

Yes, it's often difficult to follow explanations of GUI processes
because they're interactive by nature. Sometimes a video is more
help than written instructions. The modern world …

Cheers,
David.

Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

Richard Owlett-3
On 04/15/2019 09:15 AM, David Wright wrote:

> [snip]
>
>> Using "dot -Tps  dependency-graph.dot > owl.ps" I got a displayable,
>> if not readable, graph. There was a warning in what I had read about
>> "dotty" about viewablity issues if the graph was too complex. Suspect
>> that is problem.
>
> Add   -o APT::Cache::GivenOnly=1   to the commandline, and you'll get
> a much smaller graph. I haven't figured out why python and
> python-requests are missng from the graph, or is this a stretch/buster
> difference. (I'm comparing the graph with the Packages entry:
>

Neither
   > $ dot -Tps -o APT::Cache::GivenOnly=1 dependency-graph.dot > owl2.ps
Nor
   > $ dot -o APT::Cache::GivenOnly=1 dependency-graph.dot
gave useful output.

I'll do some reading and try on something simpler.
Thanks



Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

David Wright-3
On Mon 15 Apr 2019 at 10:13:31 (-0500), Richard Owlett wrote:

> On 04/15/2019 09:15 AM, David Wright wrote:
> > [snip]
> >
> > > Using "dot -Tps  dependency-graph.dot > owl.ps" I got a displayable,
> > > if not readable, graph. There was a warning in what I had read about
> > > "dotty" about viewablity issues if the graph was too complex. Suspect
> > > that is problem.
> >
> > Add   -o APT::Cache::GivenOnly=1   to the commandline, and you'll get
> > a much smaller graph. I haven't figured out why python and
> > python-requests are missng from the graph, or is this a stretch/buster
> > difference. (I'm comparing the graph with the Packages entry:
> >
>
> Neither
>   > $ dot -Tps -o APT::Cache::GivenOnly=1 dependency-graph.dot > owl2.ps
> Nor
>   > $ dot -o APT::Cache::GivenOnly=1 dependency-graph.dot
> gave useful output.

I'm not sure how you expect to progress if you expect people here,
following your blow by blow account, to write each commandline for
you in full.

It's fairly obvious that APT::Cache::GivenOnly applies to the
apt-cache command, given the words it has in common. In fact,
it's likely you have some options like this in your /etc/apt/
tree, eg:

/etc/apt/apt.conf.d/00trustcdrom :
APT::Authentication::TrustCDROM "true";

Cheers,
David.

Reply | Threaded
Open this post in threaded view
|

Re: Exploring package interrelationships

Curt
In reply to this post by Richard Owlett-3
On 2019-04-15, Richard Owlett <[hidden email]> wrote:

>>
>
> Neither
>    > $ dot -Tps -o APT::Cache::GivenOnly=1 dependency-graph.dot > owl2.ps
> Nor
>    > $ dot -o APT::Cache::GivenOnly=1 dependency-graph.dot
> gave useful output.
>
> I'll do some reading and try on something simpler.
> Thanks
>
>

That doesn't seem to be how you're supposed to do it.

I'm reading

Create the graph (with no package given all packages in the cache are
graphed):

 apt-cache dotty apache2 > apache-dependency-graph.dot

Visualize the graph:

 dot -Tpng apache-dependency-grap.dot

But there's still too much stuff in there maybe to be legible. DW
suggests a restriction of the graph to only the packages given on the
command line.

 apt-cache -o APT::Cache::GivenOnly=1 dotty apache2 apache2-common (etc.).

http://www.macfreek.nl/memory/Dependency_Graph_Debian_Packages