LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 12-23-2015, 12:09 PM   #16
Drakeo
Senior Member
 
Registered: Jan 2008
Location: Urbana IL
Distribution: Slackware, Slacko,
Posts: 3,716
Blog Entries: 3

Rep: Reputation: 483Reputation: 483Reputation: 483Reputation: 483Reputation: 483

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.
 
Old 12-23-2015, 01:42 PM   #17
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,559

Rep: Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351
That's the point - it doesn't say that any more in the default slackpkg.conf :-)
 
Old 12-24-2015, 04:11 AM   #18
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 2,943

Rep: Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526
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
 
Old 12-24-2015, 07:45 PM   #19
Drakeo
Senior Member
 
Registered: Jan 2008
Location: Urbana IL
Distribution: Slackware, Slacko,
Posts: 3,716
Blog Entries: 3

Rep: Reputation: 483Reputation: 483Reputation: 483Reputation: 483Reputation: 483
Quote:
Originally Posted by rworkman View Post
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.
 
1 members found this post helpful.
Old 12-24-2015, 09:01 PM   #20
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,559

Rep: Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351Reputation: 1351
Satisfying Solstice to you as well
 
Old 06-15-2016, 01:28 PM   #21
hendrickxm
Member
 
Registered: Feb 2014
Posts: 344

Rep: Reputation: Disabled
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.
 
Old 06-15-2016, 02:04 PM   #22
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 2,454

Rep: Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347Reputation: 8347
Quote:
Originally Posted by hendrickxm View Post
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.
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.
 
12 members found this post helpful.
Old 03-27-2018, 05:59 AM   #23
Ne01eX
Member
 
Registered: Mar 2018
Location: Ekaterinburg region, Ural, Russian Federation
Distribution: Slackware, RTK GNU/Linux
Posts: 173

Rep: Reputation: 22
Talking

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! :-)

Last edited by Ne01eX; 03-27-2018 at 06:03 AM.
 
Old 03-27-2018, 11:07 AM   #24
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,531

Original Poster
Rep: Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271
Quote:
Originally Posted by Ne01eX View Post
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 View Post
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 View Post
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.

Last edited by drmozes; 03-27-2018 at 11:09 AM.
 
3 members found this post helpful.
Old 10-16-2019, 02:10 PM   #25
Okie
Senior Member
 
Registered: Mar 2002
Location: Oklahoma
Posts: 1,154

Rep: Reputation: 187Reputation: 187
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
 
Old 02-15-2021, 05:42 PM   #26
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware
Posts: 484

Rep: Reputation: Disabled
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?
 
2 members found this post helpful.
Old 02-16-2021, 09:22 PM   #27
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2-Multilib XDM/FVWM3
Posts: 780

Rep: Reputation: 260Reputation: 260Reputation: 260
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.

Last edited by bamunds; 02-17-2021 at 09:17 AM.
 
Old 02-16-2021, 10:12 PM   #28
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware
Posts: 484

Rep: Reputation: Disabled
Good point. Perhaps a new thread should have a title something like, "Managing aaa_libraries (Slackware 15.0+)".
 
1 members found this post helpful.
Old 03-13-2021, 12:23 AM   #29
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,531

Original Poster
Rep: Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271Reputation: 1271
Quote:
Originally Posted by gus3 View Post
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.
 
Old 03-13-2021, 02:39 AM   #30
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 2,943

Rep: Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526Reputation: 1526
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!
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Strategies for managing very frequent Fedora package updates? penyuan Fedora 5 08-23-2014 03:06 AM
First release of compat32pkg. A simple tool for managing package to format compat32.. phenixia2003 Slackware 12 09-24-2010 07:02 AM
Problem in package managing through GUI zombiechum Linux - Networking 1 11-04-2009 05:50 PM
package managing questions for newbie wakeboarder3780 Slackware 9 04-25-2006 07:13 PM
Slackware package managing system moses Slackware 11 01-08-2003 01:55 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 04:58 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration