[arch-general] Why irrelevant updates? - Arch-general - lists.archlinux.org

newer
[arch-general] Linux kernel...

[arch-general] Why irrelevant updates?

older
[arch-general] fresh install:...

Francis Gerund

13 May 2015 13 May '15

12:45 a.m.

Sometimes pacman presents updates that just don't seem to apply to my system. Just one example: sudo pacman -Syyuv presents btrfs-progs, even though: 1) I do not, and have not, used the Btrfs file system with my Arch setup. 2) It is "Required by: None" 3) It is "Optional for: None" But I hate to reject it. After all, there must be some reason it was presented . . . right? So, if I just say "yes" to all upgrades, won't my system over time get weighed down by excess stuff, until it grinds to a halt? Or, if I just make my best guess at what is really need and reject the rest, won't I have a Frankenstein system that will eventually break? And why, why, why doesn't it just present upgrades appropriate for my system?

Show replies by date

Scott Lawrence

13 May 13 May

12:51 a.m.

Hi, pacman will request to update all installed packages. If you think you don't need a certain package, -Rscn it. Not upgrading a package that you nevertheless keep installed is probably a Bad Idea (as you realize). That being said, there's no major disadvantage (disk space issues notwithstanding) to having packages installed that you never use. If those programs aren't ever run, then they won't slow anything down. On Tue, 12 May 2015, Francis Gerund wrote:

Sometimes pacman presents updates that just don't seem to apply to my system.

Just one example: sudo pacman -Syyuv presents btrfs-progs, even though:

1) I do not, and have not, used the Btrfs file system with my Arch setup.

2) It is "Required by: None"

3) It is "Optional for: None"

But I hate to reject it. After all, there must be some reason it was presented . . . right?

So, if I just say "yes" to all upgrades, won't my system over time get weighed down by excess stuff, until it grinds to a halt?

Or, if I just make my best guess at what is really need and reject the rest, won't I have a Frankenstein system that will eventually break?

And why, why, why doesn't it just present upgrades appropriate for my system?

Marshall Neill

12:52 a.m.

Could it be it was installed during installation. I have found reiser, btrfs and journal file programs of which I only use ext4. On 05/12/2015 05:45 PM, Francis Gerund wrote:

Sometimes pacman presents updates that just don't seem to apply to my system.

Just one example: sudo pacman -Syyuv presents btrfs-progs, even though:

1) I do not, and have not, used the Btrfs file system with my Arch setup.

2) It is "Required by: None"

3) It is "Optional for: None"

But I hate to reject it. After all, there must be some reason it was presented . . . right?

So, if I just say "yes" to all upgrades, won't my system over time get weighed down by excess stuff, until it grinds to a halt?

Or, if I just make my best guess at what is really need and reject the rest, won't I have a Frankenstein system that will eventually break?

And why, why, why doesn't it just present upgrades appropriate for my system?

Oliver Temlin

1:35 a.m.

On May 13, 2015 12:45:58 AM CEST, Francis Gerund wrote:

Sometimes pacman presents updates that just don't seem to apply to my system.

Just one example: sudo pacman -Syyuv presents btrfs-progs, even though:

1) I do not, and have not, used the Btrfs file system with my Arch setup.

2) It is "Required by: None"

3) It is "Optional for: None"

But I hate to reject it. After all, there must be some reason it was presented . . . right? Every installed package is updated on your system. Btrfs-progs is part of the base group, which is part of most arch installations.

So, if I just say "yes" to all upgrades, won't my system over time get weighed down by excess stuff, until it grinds to a halt? No, since updates rarely ever bring new software to your machine and cleaning the pacman cache gets rid of the additional storage space as well.

Or, if I just make my best guess at what is really need and reject the rest, won't I have a Frankenstein system that will eventually break? You could try doing that, most packages will have the correct dependencies and complain on a breaking uninstall, but others (usually in community) just plainly (and fairly in terms of packaging effort) expect that you have everything installed from the base group.

And why, why, why doesn't it just present upgrades appropriate for my system? You have an outdated version of a package installed. It might not even work when some of its dependencies are newer than itself.

--Oliver Temlin

Francis Gerund

4:21 a.m.

Okay guys, thanks for the info. I didn't know about and hadn't thought about all the packages in the base group being mandatory (or at least "expected" by other packages). And yes, I find installed automatically, packages for: -ext -jfs -reiser -xfs and who knows what else . . . Even though I also am only using ext4 (and a swap partition). On Tue, May 12, 2015 at 6:35 PM, Oliver Temlin wrote:

...
Sometimes pacman presents updates that just don't seem to apply to my system.

Just one example: sudo pacman -Syyuv presents btrfs-progs, even though:

1) I do not, and have not, used the Btrfs file system with my Arch setup.

2) It is "Required by: None"

3) It is "Optional for: None"

But I hate to reject it. After all, there must be some reason it was presented . . . right? Every installed package is updated on your system. Btrfs-progs is part of

On May 13, 2015 12:45:58 AM CEST, Francis Gerund wrote: the base group, which is part of most arch installations.

...
So, if I just say "yes" to all upgrades, won't my system over time get weighed down by excess stuff, until it grinds to a halt? No, since updates rarely ever bring new software to your machine and cleaning the pacman cache gets rid of the additional storage space as well.

...
Or, if I just make my best guess at what is really need and reject the rest, won't I have a Frankenstein system that will eventually break? You could try doing that, most packages will have the correct dependencies and complain on a breaking uninstall, but others (usually in community) just plainly (and fairly in terms of packaging effort) expect that you have everything installed from the base group.

...
And why, why, why doesn't it just present upgrades appropriate for my system? You have an outdated version of a package installed. It might not even work when some of its dependencies are newer than itself.

--Oliver Temlin

Eli Schwartz

5:51 a.m.

On Tue, May 12, 2015 at 9:21 PM, Francis Gerund wrote:

Okay guys, thanks for the info.

I didn't know about and hadn't thought about all the packages in the base group being mandatory (or at least "expected" by other packages).

And yes, I find installed automatically, packages for: -ext -jfs -reiser -xfs and who knows what else . . .

Even though I also am only using ext4 (and a swap partition).

Yes, and those aren't the only things installed in the base group that aren't really necessary. -nano -vi -mdadm -lvm2 -cryptsetup -s-nail -dhcpcd -netctl -licenses It is what it is. FWIW -- I don't think they are "expected", base is a guideline and other packages should not be making assumptions (and usually don't). I think it could reasonably be expected that one has things like bash/sed/tar installed, but anything likely to be manually removed from base I expect to be listed in package dependencies. -- Eli Schwartz

Vitor Eiji Justus Sakaguti

7:12 a.m.

On Wed, May 13, 2015 at 12:51 AM, Eli Schwartz wrote:

It is what it is. FWIW -- I don't think they are "expected", base is a guideline and other packages should not be making assumptions (and usually don't).

I think it could reasonably be expected that one has things like bash/sed/tar installed, but anything likely to be manually removed from base I expect to be listed in package dependencies.

Actually, the wiki says that the base group is always assumed to be installed [1] and many packages will not explicitly depend on anything that is in the base group even though it does depend on it in reality. Some bug reports about package dependencies are closed because the dependency is in the base group [2]. [1] https://wiki.archlinux.org/index.php/Makepkg [2] https://bugs.archlinux.org/task/34024 Best regards, Vitor Sakaguti

Daniel Micay

8:27 a.m.

On 13/05/15 01:12 AM, Vitor Eiji Justus Sakaguti wrote:

On Wed, May 13, 2015 at 12:51 AM, Eli Schwartz wrote:

...
It is what it is. FWIW -- I don't think they are "expected", base is a guideline and other packages should not be making assumptions (and usually don't).

I think it could reasonably be expected that one has things like bash/sed/tar installed, but anything likely to be manually removed from base I expect to be listed in package dependencies.

Actually, the wiki says that the base group is always assumed to be installed [1] and many packages will not explicitly depend on anything that is in the base group even though it does depend on it in reality. Some bug reports about package dependencies are closed because the dependency is in the base group [2].

[1] https://wiki.archlinux.org/index.php/Makepkg [2] https://bugs.archlinux.org/task/34024

The base and base-devel groups are installed in the containers used for building, so it's quite sane to assume they're present as build deps. The current situation is that the runtime dependencies on base (but not base-devel) are often implicit. The wiki is only documenting the status quo which is that removing base packages can cause breakage and there's nothing more official than the current state of official packages. The wiki page itself isn't an authoritative source though. It says whatever the last person to edit it wanted it to say. The base group itself would need cyclic dependencies to accurately describe things. For example, some standard C functions need to spawn a shell so glibc and bash have a dependency cycle in practice. Someone might want to start with just filesystem and glibc in a minimal container, but that's not really going to work. There's no perfect solution. I think it makes more sense to add some more explicit dependencies as needed to make minimal containers easier and call it a day.

Doug Newgard

8:52 a.m.

On Wed, 13 May 2015 02:27:14 -0400 Daniel Micay wrote:

The base and base-devel groups are installed in the containers used for building, so it's quite sane to assume they're present as build deps.

That hasn't been true for a while now. Build roots, by default, only include base-devel.

Daniel Micay

9:15 a.m.

On 13/05/15 02:52 AM, Doug Newgard wrote:

On Wed, 13 May 2015 02:27:14 -0400 Daniel Micay wrote:

...
The base and base-devel groups are installed in the containers used for building, so it's quite sane to assume they're present as build deps.

That hasn't been true for a while now. Build roots, by default, only include base-devel.

Oh right. Packages can't really get away with implicit deps on base in many cases then. It'll break if they try to link against a library or if they actually have a check() function running a test suite. I think it can be considered a bug if running the program in check() doesn't work.

Daniel Micay

9:16 a.m.

On 13/05/15 03:15 AM, Daniel Micay wrote:

On 13/05/15 02:52 AM, Doug Newgard wrote:

...
On Wed, 13 May 2015 02:27:14 -0400 Daniel Micay wrote:

...
The base and base-devel groups are installed in the containers used for building, so it's quite sane to assume they're present as build deps.

That hasn't been true for a while now. Build roots, by default, only include base-devel.

Oh right. Packages can't really get away with implicit deps on base in many cases then. It'll break if they try to link against a library or if they actually have a check() function running a test suite. I think it can be considered a bug if running the program in check() doesn't work.

The unsaid rule is really "packages can have implicit runtime dependencies on packages that are in both the base and base-devel groups".

3273

Age (days ago)

3274

Last active (days ago)

Download

10 comments

8 participants

tags

participants (8)

Daniel Micay
Doug Newgard
Eli Schwartz
Francis Gerund
Marshall Neill
Oliver Temlin
Scott Lawrence
Vitor Eiji Justus Sakaguti