LinuxQuestions.org - Managing the aaa

Page 2 of 3

Show 50 post(s) from this thread on one page

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Managing the aaa_elflibs package (https://www.linuxquestions.org/questions/slackware-14/managing-the-aaa_elflibs-package-4175537158/)

Drakeo

12-23-2015 12:09 PM

Well then I guess people that are using slackpkg and the person packing that tarball of scripts. they should not keep sending it out like this.

Code:

#

# aaa_elflibs can't be updated.

#

aaa_elflibs

Pat a few years back said hey you can upgrade them. But the person that is maintaining slackware "Pat"keeps putting slackpkg in with the same blacklist. Now slackpkg has been upgraded a couple times now and it is still there. The confusion is at the people maintaining the distribution that keep sending the tools to the users. So I remember when Slackpkg was not Part of the distro it was an extra.
You may want to patch that blacklist and get some slack back. Praise Bob.
I know it is a conspiracy.

rworkman

12-23-2015 01:42 PM

That's the point - it doesn't say that any more in the default slackpkg.conf :-)

chrisretusn

12-24-2015 04:11 AM

The default blacklist in -current reads as follows:

Code:

# This is a blacklist file. Any packages listed here won't be

# upgraded, removed, or installed by slackpkg.

#

# The correct syntax is:

#

# To blacklist the package xorg-server-1.6.3-x86_64-1 the line will be:

# xorg-server

#

# DON'T put any space(s) before or after the package name or regexp.

# If you do this, the blacklist will NOT work.



#

# Automated upgrade of kernel packages aren't a good idea (and you need to

# run "lilo" after upgrade). If you think the same, uncomment the lines

# below 

#

#kernel-firmware

#kernel-generic

#kernel-generic-smp

#kernel-headers

#kernel-huge

#kernel-huge-smp

#kernel-modules

#kernel-modules-smp

#kernel-source



#

# aaa_elflibs should NOT be blacklisted!

#



# You can blacklist using regular expressions.

#

# Don't use *full* regex here, because all of the following 

# will be checked for the regex: series, name, version, arch, 

# build and fullname.

#

# This one will blacklist all SBo packages:

#[0-9]+_SBo

Drakeo

12-24-2015 07:45 PM

Quote:

Originally Posted by rworkman (Post 5468111)

That's the point - it doesn't say that any more in the default slackpkg.conf :-)

point is happy Xmas took four years read the way back machine. I know i get high.

rworkman

12-24-2015 09:01 PM

Satisfying Solstice to you as well :)

hendrickxm

06-15-2016 01:28 PM

Has it ever been considered to add some kind of way to inform a user that installing/upgrading package X will override files owned by other packages?
I use CRUX and when you upgrade/install a package, it sometimes contains a newer executable/library that will override an older one. An example is sulogin that used to be from sysvinit but changed to the one that comes with util-linux.

The document sums it up here:

Code:

Slackware current branch

````````````````````````



3. You should not upgrade aaa_elflibs in -current that's old and stale _after_

  other upgrades.

  For example: if aaa_elflibs was updated two months ago in -current, but you

  skipped it and upgraded other packages, you should not go back and upgrade to

  that aaa_elflibs because there is a possibility that it'll downgrade to

  previous versions of libraries.  This is because some packages such as CUPS

  do not version their library file names.

volkerdi

06-15-2016 02:04 PM

Quote:

Originally Posted by hendrickxm (Post 5561376)

That's a CRUX bug then. In Slackware -current there is only one sulogin, and it is found in the shadow package.

Not to say there aren't a few overlaps in Slackware, but generally these will be lesser used things and have been deemed "mostly harmless".

Quote:

The document sums it up here:

Code:

Slackware current branch

````````````````````````



3. You should not upgrade aaa_elflibs in -current that's old and stale _after_

  other upgrades.

  For example: if aaa_elflibs was updated two months ago in -current, but you

  skipped it and upgraded other packages, you should not go back and upgrade to

  that aaa_elflibs because there is a possibility that it'll downgrade to

  previous versions of libraries.  This is because some packages such as CUPS

  do not version their library file names.

You'll notice that lately every time any library in Slackware -current is upgraded, and it's a library that also has a copy in aaa_elflibs, that aaa_elflibs is also respun. So hopefully there will never be a case where aaa_elflibs in -current is stale.

Ne01eX

03-27-2018 05:59 AM

aaa_elflibs - for users who do not use "normal" packages;

Same as glibc-solibs - for users who do not use glibc;

Same as openssl-solibs - for users who do not use openssl.

This is packages need only for build very small Slackware system. Enjoy, but do not mix! :-)

drmozes

03-27-2018 11:07 AM

Quote:

Originally Posted by Ne01eX (Post 5835948)

aaa_elflibs - for users who do not use "normal" packages;

It isn't.

Quote:

Same as glibc-solibs - for users who do not use glibc;

It's for people who don't need to compile anything.

Quote:

Originally Posted by Ne01eX (Post 5835948)

Same as openssl-solibs - for users who do not use openssl.

It's for people who don't need to compile anything that uses openssl.

Quote:

Originally Posted by Ne01eX (Post 5835948)

This is packages need only for build very small Slackware system.

I think that the document linked in the earlier pages explains adequately what the package is for in the section entitled "Purpose of aaa_elflibs".

Quote:

Enjoy, but do not mix! :-)

As long as the base package and the -solibs one are in sync (from a version and build perspective), it's fine.
If not, one will always win depending on the installation order.
e.g. if you had openssl-1.2-arm-1 and openssl-solibs-1.2-arm both installed, then upgraded to openssl-1.3-arm-1 (but not the -solibs package), then the libraries from the solibs package would be overwritten by those from openssl-1.3-arm-1; and vice versa.

Okie	10-16-2019 02:10 PM

from the changelog:
Mon Oct 14 19:50:41 UTC 2019
a/aaa_elflibs-15.0-x86_64-13.txz: Rebuilt.
Added temporarily until third party packages have been recompiled:
libdvdread.so.4.2.0.
Removed (anything still using these must be recompiled):
libicudata.so.64.2, libicui18n.so.64.2, libicuio.so.64.2,
libicutest.so.64.2, libicutu.so.64.2, libicuuc.so.64.2.

so far the only thing this upgrade make me do is i did have to abandon qt-5.7.1 and upgrade to qt-5.9.8, and a few hours later all was good again, qt-5.x sure takes a long time to build on this old PC

gus3	02-15-2021 05:42 PM

aaa_elflibs is now called aaa_libraries, and glibc has been broken out into aaa_glibc-solibs. Perhaps it's time to start a new thread, using up-to-date information about managing these packages, and then close this thread?

bamunds

02-16-2021 09:22 PM

I'd rather see this remain a sticky until Pat EOL's older releases. I believe 13.37, 14.0, and 14.2 are continuing to be supported. Since I still use and plan to use 14.2 which has this package, the note is appropriate. Not everyone wants to upgrade their desktops and servers to only the latest testing branch.

gus3	02-16-2021 10:12 PM

Good point. Perhaps a new thread should have a title something like, "Managing aaa_libraries (Slackware 15.0+)".

drmozes

03-13-2021 12:23 AM

Quote:

Originally Posted by gus3 (Post 6221160)

Good point. Perhaps a new thread should have a title something like, "Managing aaa_libraries (Slackware 15.0+)".

It's unnecessary to maintain this thread as the aaa_libraries package is updated when its components change, so there's no need for any special treatment. For the previous releases, there are no newer aaa_elflibs packages shipped post release - this thread was originally for -current.

chrisretusn

03-13-2021 02:39 AM

Agree there really isn't any "management" required now.

/etc/slackpkg/blacklist 14.2

Code:

#

# aaa_elflibs should NOT be blacklisted!

#

/etc/slackpkg/blacklist 15.0 or -current

Code:

# aaa_libraries should NOT be blacklisted!

All times are GMT -5. The time now is 11:16 AM.

Page 2 of 3

Show 50 post(s) from this thread on one page