LinuxQuestions.org
Register a domain and help support LQ
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 03-07-2013, 12:48 PM   #256
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,592
Blog Entries: 2

Rep: Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047

The real problem with having multilib packages in /extra are updates. If you use slackpkg to update the system all packages that have updates must appear in the changelog, otherwise slackpkg doesn't know about them. This means that Pat not only must provide updates to the multilib packages, but they must also be mentioned in the changelog, which will bring problems on systems that don't have those packages installed, if I understand that correctly.

I personally don't see use for having multilib in the tree, if I want to install it I can easily download the packages from AlienBob or simply let multilibpkg/compat32pkg do the job. I would rather see those tools and sbopkg in the tree instead of the multilib packages.
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 03-07-2013, 01:00 PM   #257
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,313

Rep: Reputation: Disabled
Slackpkg does not use the ChangeLog.txt when scanning for updated packages. It will use the ChangeLog.txt for newly "Added" packages.

Eric
 
Old 03-07-2013, 01:00 PM   #258
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,313

Rep: Reputation: Disabled
Slackpkg does not use the ChangeLog.txt when scanning for updated packages. It will use the ChangeLog.txt for newly "Added" packages.

Eric
 
1 members found this post helpful.
Old 03-07-2013, 01:08 PM   #259
Buumi
Member
 
Registered: Dec 2010
Distribution: Slackware
Posts: 52

Rep: Reputation: 5
Well, not a perfect fit for that thread but I'd like to see glew updated for selfish reasons and as it hasn't been updated since 13.37. Latest Spring RTS doesn't build with 1.5.7 that comes with slackware.
 
Old 03-07-2013, 01:13 PM   #260
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,592
Blog Entries: 2

Rep: Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047
Quote:
Originally Posted by Alien Bob View Post
Slackpkg does not use the ChangeLog.txt when scanning for updated packages. It will use the ChangeLog.txt for newly "Added" packages.

Eric
Thanks for the clarification, seems that I mixed that up.
 
Old 03-07-2013, 01:42 PM   #261
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
Quote:
Maybe under /extra on the DVD... Or perhaps as an option during installation.
I wish /extra would become a community repository for non stock packages. One of the leading attractions of other distros is the huge number of final packages that are available. Slackware never had that.

Pat could maintain the packages he wants in /extra but could open the door to other Slackers to upload packages. Each individual who uploads a package is responsible to maintain that package or the package gets pulled. To be included in the repository each uploaded package must include a contact address so users can seek support and report bugs. Add some official disclaimers about support, etc., etc.

Some folks will argue that slackbuilds.org fills this purpose. Not quite. There, only build scripts are provided, not final packages. New users don't know how to build packages yet they want and need additional software. There are times when people have hectic schedules and downloading packages is more convenient than compiling. Remember that many people like Slackware because of the design philosophy and not because they like building packages from source.

Those who prefer to build their own packages can still download the build scripts and build locally.

Nothing unusual about the idea. All of the large distro repositories are nothing more than build scripts and packages maintained by community members.

Pushing some of the stock packages to /extra could alleviate much of the debate about what should or should not be part of the final release. Between the final DVD and /extra all Slackware users would find almost all they might need or want.

Would be nice to see gslapt ported to Qt4 too so there would be a nice GUI package manager for KDE. Both the GTK and Qt version could be part of /extra. Again, nobody is required to use that app as a package manager but the option would be available.

Just ideas.
 
1 members found this post helpful.
Old 03-07-2013, 02:22 PM   #262
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,391

Rep: Reputation: 1091Reputation: 1091Reputation: 1091Reputation: 1091Reputation: 1091Reputation: 1091Reputation: 1091Reputation: 1091
Quote:
Originally Posted by Woodsman View Post
I wish /extra would become a community repository for non stock packages.
I don't think that will ever happen, as that would mean including in Slackware packages whose quality and proper integration in the distribution Pat wouldn't check. I can hardly believe he will accept that.

No disclaimer will ever prevent a user to think that Pat is responsible for anything included in Slackware.

This doesn't mean that a repository of packages of the same quality and care of proper integration in Slackware as SlackBuilds provided by http://slackbuilds.org would'nt be useful, only it has to be outside Slackware proper, IMO.

Even then this repository would have to deal with dependencies issues, either in statically including in every package all dependencies not shipped in a full Slackware installation (as Alien BOB does for his vlc packages, for instance), or providing "sets" of packages to be installed together (in the same vein as the queues used in conjunction with sbpokg, for instance). You will have to find volunteers committed in the long term then
 
1 members found this post helpful.
Old 03-07-2013, 02:25 PM   #263
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,391

Rep: Reputation: 1091Reputation: 1091Reputation: 1091Reputation: 1091Reputation: 1091Reputation: 1091Reputation: 1091Reputation: 1091
<duplicate post>

Last edited by Didier Spaier; 03-07-2013 at 03:01 PM.
 
Old 03-07-2013, 03:00 PM   #264
foodown
Member
 
Registered: Jun 2009
Location: Texas
Distribution: Slackware
Posts: 609

Rep: Reputation: 218Reputation: 218Reputation: 218
Quote:
Originally Posted by Woodsman View Post
I wish /extra would become a community repository for non stock packages.

...

Just ideas.
Pretty good idea, but I think /extra has a much more narrow scope from what you're talking about.

I think what you're describing is something like the EPEL repository in the CentOS/RedHat world. (Extra Packages for Enterprise Linux)

It'd be cool ... with all of the packages available on Alien's site, we almost have that already.
 
Old 03-07-2013, 03:02 PM   #265
ilmich
LQ Newbie
 
Registered: Mar 2013
Posts: 3

Rep: Reputation: Disabled
I'd like to see dconf as official package, because Slackware has support for gsettings in glib, but not a valid backend for it.

Another thing that I think is useful (but I'm not sure that this is the right place to ask) is to package lzo, in the same way as other compression library (gzip, lzma etc etc), with libraries in /lib and not in /usr/lib.
I ask this because I'm trying to use fusecompress to compress /usr folder, and with the existing package, it's not possible to use lzo algorithm at boot.
 
Old 03-07-2013, 03:02 PM   #266
ilmich
LQ Newbie
 
Registered: Mar 2013
Posts: 3

Rep: Reputation: Disabled
<duplicate post>

Last edited by ilmich; 03-07-2013 at 03:04 PM.
 
Old 03-07-2013, 03:43 PM   #267
mina86
Member
 
Registered: Aug 2008
Distribution: Slackware
Posts: 393

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by elyk View Post
Is there any reason for keeping libtermcap around when we have ncurses/terminfo? I know there are several threads here that are solved by adding stuff to the default /etc/termcap, such as support for "xterm-256color".
Yeah, I was wondering that myself, it took me a long while to figure out why shell did not behave as it should under urxvt…

Quote:
Originally Posted by TobiSGD View Post
if I want to install it I can easily download the packages from AlienBob or simply let multilibpkg/compat32pkg do the job.
You can make that argument about every piece of software.

Last edited by mina86; 03-07-2013 at 03:45 PM.
 
Old 03-07-2013, 04:28 PM   #268
tuxbg
Member
 
Registered: Sep 2012
Location: Bulgaria,Varna
Distribution: Slackware64
Posts: 249

Rep: Reputation: Disabled
Awesome WM
 
1 members found this post helpful.
Old 03-07-2013, 05:59 PM   #269
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,592
Blog Entries: 2

Rep: Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047
Quote:
Originally Posted by mina86 View Post
You can make that argument about every piece of software.
Of course I can, but in this special case we have already a repository for those packages, managed by a well known and trusted Slackware developer. I can't see any benefits from moving this repository to the Slackware tree. As I stated, IMHO it would be the better option to just make it easier to install those packages from the already existing repository using the already existing (and well working) tools multilibpkg and compat32pkg (which not only help with the initial install, but also with adding libraries and keeping the multilib packages up to date, all without putting any additional work on the distro developers) with putting those tools into the tree instead.
sbopkg, src2pkg, multilibpkg and compat32pkg should be all that a Slacker ever needs, besides the usual suspects install-/upgrade-/remove-/make-/explodepkg.
 
1 members found this post helpful.
Old 03-07-2013, 09:49 PM   #270
ngc891
Member
 
Registered: Jan 2012
Location: South Korea
Distribution: Slackware64 OpenBSD
Posts: 50

Rep: Reputation: Disabled
Quote:
Originally Posted by Woodsman View Post
I wish /extra would become a community repository for non stock packages. One of the leading attractions of other distros is the huge number of final packages that are available. Slackware never had that.

Pat could maintain the packages he wants in /extra but could open the door to other Slackers to upload packages. Each individual who uploads a package is responsible to maintain that package or the package gets pulled. To be included in the repository each uploaded package must include a contact address so users can seek support and report bugs. Add some official disclaimers about support, etc., etc.

Some folks will argue that slackbuilds.org fills this purpose. Not quite. There, only build scripts are provided, not final packages. New users don't know how to build packages yet they want and need additional software. There are times when people have hectic schedules and downloading packages is more convenient than compiling. Remember that many people like Slackware because of the design philosophy and not because they like building packages from source.

Those who prefer to build their own packages can still download the build scripts and build locally.
I couldn't agree more. The relatively low number of packages is a common criticism I heard from people not wanting to try Slackware. Isn't this thread about adding more packages? It seems to be a concern for slackers too...

Available slackbuilds like the SBo project is really nice but it doesn't really solve important problems:

a) Multiplicity. People tends to reinvent the wheel instead of mutualizing. Do we have so much manpower?
There are really a lot of slackbuilds around that do almost the same thing. That's because writing a slackbuild is cheap. How does this help someone looking for a package? SBo is a try to federate. Maybe. Just looking at the E17 SBo slackbuilds, started in 2010. Seems the authors didn't bother to google before starting as I provide e17 slackbuilds (and packages) since 2005. Nobody contacted me. I have commit access to the E17 code and already used it to make things working better on Slackware. Having several sources of slackbuilds doesn't help fixing users problems.

b) Time. Slackware is not Gentoo. Slackware is about control. You can compile your own packages shouldn't mean that you have to do it every time. Seriously, is there a majority of people here that prefer to build LibreOffice from source instead of getting the ones from AlienBob? How is it a progress for thousand of people to compile the same thing (and sometimes getting trouble)? It's often a waste of time and that's why people are asking for more in stock Slackware.

c) Quality. "Use slackbuilds" is like saying "Here is a cookbook, now you can open a successful restaurant". Quite misleading. People are compiling on different systems (slackware versions, third-party packages/dependencies), sometimes you can even have an hardware bug. So everybody ends up with a different binary. You can't be sure why someone gets a problem with your slackbuild. Compiling and testing packages is a much bigger work than writing slackbuilds but it's the only way to get quality.

SBo is definitively useful but it can not replace prebuild packages. As I am not willing to build LibreOffice, openJDK or the last ffmpeg every time an update is out there. I really think that having an official extra Slackware repo with slackbuilds and packages will help. With software sets, and with ONE people specifically responsible for building the (signed) packages for each set. I'm already seeing how much popular this would be. Technically, it's just a matter of adding a web page to slackware.com which points to a community git repo (github/SF/etc).
 
  


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
slackbuild textlive on slackware 13 missing texmf tree balamkej Slackware 4 01-21-2010 03:19 PM
A script that could mirror slackware tree from multiple servers grissiom Slackware 8 11-21-2009 07:05 PM
suggestions on family tree programs and..... Chris106 Linux - General 2 10-22-2008 07:54 AM
Linux Family Tree -- Where Slackware Fits unixfool Slackware 16 04-23-2008 11:47 PM
Slackware 9.1 tree/slapt-get question 187807 Slackware 3 02-20-2004 06:36 PM


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

Main Menu
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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration