There was an interesting discussion about package naming started on this thread at message 27: https://www.linuxquestions.org/quest...rs-4175602521/. The basics are how the Slackware-way to name packages is four parts app-version-arch-tag. Slackware uses dashes for the delimiting of four parts, but reads the parts from right to left, allowing app to include dashes. The problems I encountered when building some packages with src2pkg and rpm2targz are that they do NOT follow the Slackware-way of naming, and instead simply modify the name from the source binary file type. Thus leaving one with an invalid package name when using tools like pkgtool or sboui (which is an excellent frontend to sbopkg and sbotools).

The rpm2targz is a very old conversion tool where src2pkg is slightly newer but still has been available for close to a decade (I believe). In my use of both tools it seems they do not attempt to modify the resulting package to follow the Slackware-way for package naming.
1) Have other tool users experienced this same issue?
2) If you have, then how do you deal with the resulting package, simply rename it or install/upgrade as is?

Lastly, I still find some packages as binary source ( in the other thread you'll see I'm using Brave, SkypeforLinux, XnViewMP) and wish to install them for testing and daily usage. In the past if an official slackware.com build or unofficial slackbuuilds.org package wasn't available I'd look at eric's, ponce's and robby's repositories, but if not there then for an OpenSUSE rpm and use rpm2targz to make a package. I've been playing with src2pkg more in the last week and find it is a really strong tool for any source binary and use it for the XnViewMP conversion from .deb to txz. What I like about src2pkg is it allows me to create a info/slack description file which rpm2targz doesn't. Yes I know I can simply config/make & make install, but I prefer a tool that checks the config and will also store to a local repository so my slackpkg searches find it. My questions are these
3) I haven't seen any updates to either tool, src2pkg and rpm2targz, in a while so are they still maintained?
4) In my /usr/share/ folder is a symlink to /usr/docs, is that a slackware placed symlink or was it created the first time I used rpm2targz, since other distros tend to place their docs in /usr/share/doc?

Thanks in advance for advice and answers. Cheers.

1) No, because I don't use these tools.
2) If that happens, I will prefer to have a properly named package, just because that's what Slackware's package management tools expect. Honestly I didn't try "removepkg <badly named package short name>" but I am not sure that would work.
To get this result there are several possible paths:

• Rename the source archive.
• Rename the resulting package.
• Request the maintainer of the tool to "canonize" the package name in such a case. But I don't know how difficult this can be.

3)

• According to the ChangeLog Gilbert Ashley (gnashley @ LQ) last modified it on March 15 2014.
• For rpm2tagrz (shipped in the Slackware package a/rpm2tgz) see the source package. Author: David Cantrell.

I realize this doesn't answer directly your question. You would get a better answer asking the upstream developer or the maintainer.
4) Slackware have been putting all docs in /usr/doc since a long time so it is better to follow this convention.

An alternative to using those packages is to extract the rpm or deb and create your own package based on that. Here's a relatively simple one I created to repackage the discord binary package. It just extracts the .deb into a folder, then it just does the other standard SlackBuild stuff and finally it runs makepkg on it. The key line in it is:

RPMs have a similar command:

Both of these would extract their contents to the current directory. Then you can do any manipulation you need to the files or folders and then run makepkg from within that directory.

However, looking at the rpm2tgz and deb2tgz scripts, both offer a -n option that will try to name the package based on the package's metadata. I have no idea how well this works in practice, since it would likely depend heavily on how the rpms or debs are put together. Unfortunately, I have little experience with src2pkg and I'm having a hard time pulling up the source at work (not that I know I could make sense of it), so I can't comment on if that offers some similar option.

That symlink is normal. It is created by the doinst.sh in the aaa_base package (you have to extract the _aaa_base.tar.gz package to see the install/doinst.sh file).

I've had problems trying to remove packages with badly formatted names. I'm not sure if I just wasn't able to get the name right or due to pkgtools/removepkg not being able to properly determine the name due to the screwed up naming scheme.

However, you're always able to remove packages by referencing their location in /var/log/packages/

3 members found this post helpful.

@Didier Thanks I'm hoping @Gashley will answer about any plans for improvement/bug fixes or if he feels src2pkg is now complete only needing fixes if newer official packages conflict? I haven't yet discovered a way to rename the output to follow the standard format. Although there are options for version, arch, and tag which might mean you must always use them to match slackware-way naming.
The rpm2targz.README doesn't have David's email address to ask status and questions. Would someone know how to reach him?
Thanks for the feedback and ideas of alternative package building.

@bassmadrigal - also thanks for the alternative package conversion commands and for answering what created the symlink and it is normal in slackware.

I'm going to leave this open for a couple of days to see if other members will chime it with their experiences with the tools and thoughts about the package naming. Cheers.

David Cantrell works for Red Hat now and hasn't had anything to do with Slackware in over 15 years.

As far as the package naming with rpm2tgz, try using the -n option to generate a Slackware name conforming package.

1 members found this post helpful.

ALT_NAME and ALT_VERSION should fix most issues, I think.

Do you have an example of a package generated by src2pkg that isn't valid?

@Richard Cranium, actually yes the XnViewMP-linux-0.84.x64.deb binary used with src2pkg -CWD generated XnViewMP-linux-084.x64.txz until I used the v=0.86 arch=x86_64 tag=1ba and then I ended up with XnView-linux-0.84-x86_64-1ba.txz as a package. I had the same issue with rpm2tgz which had a source binary of brave-0.13.0.x86_64.rpm which generated a package name of brave-0.13.0.x86_64.tgz. So tonight I tried rpm2tgz -n brave-0.13.0.x86_64.rpm and it generated brave-0.13.0-x86_64-1.tgz just like @volkerdi said it would. YEA! Now if only there was manual for rpm2tgz that I could reference for all the options. At least I found this on github https://github.com/GArik/rpm2txz/blob/master/rpm2targz. Interesting that it says the latest update was 2010? Anyone know of a page with the options. Maybe rpm2targz is a better fit than src2pkg for rpm binary sources?

The function used by src2pkg to parse information from debian package names in /usr/libexec/src2pkg/01-pre_process does this...
XnViewMP-linux-0.84.x64.deb appears to be a misnamed debian package; at least according to https://www.debian.org/doc/manuals/d...basics.en.html
I think it should have been named XnViewMP-linux_0.84-1_amd64.deb; you still would have had to override ARCH, since I can't find where amd64 is mapped to x86_64 in the src2pkg code. (I see where x86_64 is mapped to amd64 when generating debian packages, but not the other way around.)

I don't see where tag=1ba would be used by src2pkg anywhere. If you have SIG="ba" in /etc/src2pkg/src2pkg.conf, then you'd get the final -1ba on the package name.

@RichardCranium It could be the developer of XnViewMP improperly named the original .deb binary, but that is the name as downloaded from the website.

You are correct about src2pkg, there is no tag qualifier it is -b="" or Build="". As I said, I'm still becoming familiar with all the options and processes of src2pkg :-) Src2pkg is very robust and allows more than one way to do things. For example, you can use -n= or ALT_Name= to set the package name, or use combinations of -a= -b= and -v= which set arch, build and version which would be tagged on to the package name to form the slackware-way naming. This is strictly talking about naming. There are also many ways to modify the build, including a way to automate the build for future updates, a very strong and flexible program. But perhaps rpm2tgz is just the keep it simple stupid (KISS) method that fits best, since slackware includes it officially and slackware is RPM aware, as we all know slackware for years has RPM as part of the standard install.

I didn't mean to imply otherwise, but the people at http://www.xnview.com are publishing an incorrectly named debian package. The Ubuntu folks did not just use that one, but created one that is named correctly (xnviewmp_0.84-1~getdeb2~yakkety_amd64.deb) See https://www.ubuntuupdates.org/xnviewmp

My main point was that ill-formed input can result in ill-formed output. My other point is that when you take binary packages from places that aren't part of a distribution, you run into issues such as this.

The easiest way to get the name you want using src2pkg may be by creating a link to the original binary package with the name format you want/need. src2pkg may do better wih *.deb archives than with *.rpm. Part of the problem with rpm's is that the naming standards are not uniform -most significantly, SuSe and fedora/RH are different. And, sometimes things like Opera or other closed-source stuff delivers binary rpms with their own variations.

Starting at line 391 in 01-pre_process, there is another guessing algorithm for source rpm's which I think does a better job than the code @295 -the get_my_arch may be botching something too. I'm taking note of the example you give of the XnView debian package. Was there any other specific one you had problems with(with src2pkg), debian or rpm?

@gnashley, No. The only .deb I've ever converted with src2pkg is the XnViewMP. But in interest of this conversation... Let me share my results with the another package I convert which lacked an slackware official or unofficial package.

Brave - the laptop and desktop web browser
I've attempted to run src2pkg on two binary sources from Brave.com, both the raw source and the SuSE rpm.
The raw source file is called brave.tar.bz2. Running # src2pkg brave.tar.bz2 produces "FAILED!! No INSTALL_LINE given". As expected and as you have responded back in October 2016, src2pkg is not intended for binary packaging and really is intended for .deb and .rpm conversions.
The rpm binary source is called brave.rpm. Running plain src2pkg brave.rpm produces a package called brave-brave-brave-1.txz. Opening that package shows a complete proper package structure, with an empty slack-desc, nothing in /usr/bin/ and the brave executable in /usr/share/ with root:root ownership, and documentation also empty. The rpm binary library files match the package, executable is in /usr/share/ and documentation is empty file. So in this case src2pkg did what it could with the available files and added a doinst.sh, slack-desc (empty), copied the brave.png to /usr/share/icons/hicolor/48x48/apps and moved the blank doc file to /usr/doc.
If I run src2pkg -CWD -a=x86_64 -b=2ba and -v=0.13.5 brave.rpm it will produce a package brave-0.13.5-x86_64-2ba.txz. Which has a proper package with doinst.sh, and empty slack-dsc, the doc file moved to /usr/doc/, the executable moved to /usr/share/brave/ and really the only change is that the name is proper.
If I run the brave.rpm with rmp2tgz -n -d brave.rpm it produces a package called brave-0.14.1-x86_64-1.tgz. The package has a doinst.sh (much more abbreviated from the src2pkg script without the lines to check directory/file ownership), slack-desc, empty doc file created under /usr/share/doc, and a version which is correct according to the latest version available 3/31/17 (my earlier download on 3/18/17 is 0.13.5)

The results showing that I believe rpm2tgz has done a better job converting the .rpm than src2pkg. It properly identified the version from available metadata and created a slack-desc (short "Brave, laptop and desktop browser" and the website it is from ). It created the converted file in the same directory as the source. The doinst.sh seems less intrusive, but could leave open issues of ownership on some files if I don't use the -c option with rpm2tgz. If I understood where rpm2tgz pulled the version code from, then perhaps I could change the src2pkg file name to proper -v= so then perhaps with src2pkg more verbose doinst.sh and proper movement of the empty doc to /usr/doc I'd consider src2pkg superior for rpm conversion. Certainly I can not use rpm2tgz for a .deb file like XnView.

I've tried running XnViewMP-linux-x64.deb for Ubuntu through src2pkg.
# src2pkg -a=x86_64 -b=1ba -v=0.85 XnViewMP-linux-x64.deb
It generated a package called xnview-linux-0.85-XnViewMP-linux-x64-2ba.txz.
A totally broken package name. I normally change it to a proper package name, ie xnviewmp-linux-0.85-x86_64-1ba.tgz and then use # upgradepkg --reinstall --install-new xnviewmp-linux-0.85-x86_64-1ba.tgz.
However, I download and use the source package XnViewMP-linux-x64.tgz and then run # src2pkg -i='make install' -A XnViewMP-linux-x64.tgz then it seems to hang on Checking support for DESTDIR. I know it is not meant to build slackware packages from raw binary packages, but thought I'd let you know.
Cheers

XnViewMP-linux-x64.tgz doesn't sound like a source archive. I've just tried the deb binary and get the same name mess. I never promised best results when converting foreign binary packages, but this is definitely a bug -looks like the originally guessed name is being concatenated to the cli-specified ones. src2pkg is getting the version from the 'control' file in the deb. I'll try to have a look at the problem.

1 members found this post helpful.