Desperately seeking MORE packagers - please join hands

[frazelle09]

Thanks for replying, sling-shot.

O.k.  So, i download the MiniMe - or is it the KDE .iso? and use the .iso during installation to reallocate part of my /home partition to Packaging...  Does this sound correct?

Have a cool afternoon! 

[parnote]

Hey guys!

I know I've wanted to learn packaging for a LONG time, and have (several times) tried to follow the scattered info here on the forum so I could learn at least the basics. I can -- with a struggle -- make a RPM of a "simple" app, but I would like to know more so that I can do more. Yet, the scattered nature of the information has made it difficult for me to progress. Also, my time is somewhat limited, due to my role with the magazine.

I definitely would not be opposed to running a Packaging tutorial series in the magazine. But we'd have to have someone who knows what they are doing to write the article, and as it is, it definitely has the potential to take away some time from a current packager's packaging time. But a very valid point has been made: we need to bolster the number of packagers for our own self preservation (as a distro) and it will definitely help take some of the workload off of an already overworked packaging crew.

Of course, any packaging tutorial will have to be very explicit in explaining what each command in the spec file means, and how it contributes to making a fully functional package -- without any techno-babble. And, whoever decides to take this on will have to be sure that they can and will complete the series. It would be much worse to have an incomplete tutorial series than to have no tutorial series at all.

Any takers?

parnote

[Wildman]

Hey guys!

I know I've wanted to learn packaging for a LONG time, and have (several times) tried to follow the scattered info here on the forum so I could learn at least the basics. I can -- with a struggle -- make a RPM of a "simple" app, but I would like to know more so that I can do more. Yet, the scattered nature of the information has made it difficult for me to progress. Also, my time is somewhat limited, due to my role with the magazine.

I definitely would not be opposed to running a Packaging tutorial series in the magazine. But we'd have to have someone who knows what they are doing to write the article, and as it is, it definitely has the potential to take away some time from a current packager's packaging time. But a very valid point has been made: we need to bolster the number of packagers for our own self preservation (as a distro) and it will definitely help take some of the workload off of an already overworked packaging crew.

Of course, any packaging tutorial will have to be very explicit in explaining what each command in the spec file means, and how it contributes to making a fully functional package -- without any techno-babble. And, whoever decides to take this on will have to be sure that they can and will complete the series. It would be much worse to have an incomplete tutorial series than to have no tutorial series at all.

Any takers?

parnote

+1 Very Well said parnote..

This I think has been a major hold up to many of us, who want to help, but for one reason or another (Age maybe  ) can't or won't go thru the education process to learn all the lingo needed the perform packaging process..The technical part will come with experience from doing.... ( man, does this even make sense  ok, yak is over) 

[joechimp]

My caveat would be this: Make sure this is something you really want to do. It is going to take time and dedication. Early on I was attempting to do this but I could not manage to find enough"dedicated" time to do this. Just to absorb the "manual" and various text written for this is laborious. To be able to absorb it all is indeed daunting.
Not to say that those of you more informed than I can do it faster.
I am going to revisit this and see if I can fit it in. With better tutorials, as said by others, many of us would give it a try. I am sure once I got into it I could accomplish something that would be helpful. If only a small percentage got the hang of it and you got some full time packagers out of it, I guess that would be worth the effort.
Speaking for myself a lot of this is over my head. Why , because I have not learned it yet.
Hope this all works out. It is obvious from this thread that this is something of which there is a great need.

[bullet_trap]

Yes, I would be interested in learning to package.  A few months ago, I installed mini-me onto one of my computers for the purpose of learning packaging.  As has been stated, there is lots to read and many changes in the procedures.  I am retired and living  north of Atlanta.  For me, I would  like a hands-on session with someone who already knows how to package.  Watching the packaging process and being able to ask questions would be very helpful.    An alternative might be a youtube video that would show how to package??

[TerryN]

I understand the desire to "want to learn packaging" but what is often missed is that to have any chance of understanding packaging you first have to have some knowledge of software building.  If you have never used the C compiler (gcc), configure scripts or Makefiles then the "step by step" instructions on packaging (which have been referenced here) will mean little and the error messages thrown up during the builds will completely baffle.  I think that is why a lot of people get discouraged and give up.

Terry.

[joechimp]

I understand the desire to "want to learn packaging" but what is often missed is that to have any chance of understanding packaging you first have to have some knowledge of software building.  If you have never used the C compiler (gcc), configure scripts or Makefiles then the "step by step" instructions on packaging (which have been referenced here) will mean little and the error messages thrown up during the builds will completely baffle.  I think that is why a lot of people get discouraged and give up.

Terry.

Kind of echoes what I tried to say. If you don't already have some basic knowledge then the learning curve will be astronomical.

[frazelle09]

"Kind of echoes what I tried to say. If you don't already have some basic knowledge then the learning curve will be astronomical. "

This is not very encouraging.  This leads me to ask:  Is there any basic, basic activity that those of us who may never "reach the stars" can do which will be of help/service?

Have a great afternoon! 

[gseaman]

I don't think TerryN means that if you haven't built software, that you can't start now. I think that if thay is your experience level, you should learn to build some programs first, then learn to package. You don't have to know everything, just enough to have a good overview of what is happening. Even if you don't end up packaging, you will still gain a better understanding of your system.

Galen

[Neal ManBear]

The different sections may approximately mean the following:

• base - the most basic software needed for PCLinuxOS to run.

     
No. It is the base system. That which all else goes on top of.     

• main - most of the software included in the default .iso release.

     
No. The software included in the default .iso release can be from any section. Main is the place for packages not specifically related to something else = kde, for example.     

• updates - the software which gets added after an .iso is released. This would include both new software and updates to existing software.

     
No. Updates contains the more recently updated software that is not specifically related to something else.     

• kde / xfce etc - software specific to desktop environments.

     
Yes. You have it right.     

• non-free - software distributed in the form of precompiled binaries such as graphic drivers, adobe reader etc.

     
Yes. This is the place for non-free software that we have permission to distribute.     

[If I am wrong please correct me.]

All you need to do is to enter any of these subdirectories by clicking on them and then just examine the list seen there. Click and download any one of your choice. Once it is downloaded locally, right click on the downloaded file.
You will have an option called "Install for build"
This will open a terminal window which can be closed later.
Now if you go and check inside /src/rpm/SPECS and /src/rpm/SOURCES directories of your user account you would find the respective .spec and .tar.xz files.

     
Much easier than you might think to do this.     

[Neal ManBear]

There is a lot of information in Packagers section. Each thread will have some helpful post or posts in it. You may consider this "scattered information" but please consider this - each thread was started by an individual seeking assistance with packaging a specific app. Digging out those gems of information may take time, but if you are serious about packaging, the effort will be worth it.     
Aside from those, there are the sticky topics. These, also, are worth the read.     

Start your own topic in Packagers section, when you get started on packaging an app. Share your SRPM. Share your spec. Ask questions. You can learn from the responses you get.     

[TerryN]

Kind of echoes what I tried to say. If you don't already have some basic knowledge then the learning curve will be astronomical.

Yes it will be a steep learning curve but not impossible.  If you are the sort of person that enjoys the challenge of taking something that doesn't work, figuring out (by research, learning and testing) what is wrong with it and making it work then you can succeed on this learning curve and will get great satisfaction in the process.  On the other hand, if you are the sort of person that just wants to blindly follow step-by-step instructions (without understanding) and throw your hands up in the air and quit as soon as something doesn't do what it's supposed to then you will find it very hard.

In a curious way, learning packaging by piecing together sparse and obscure information is actually a good introduction to what the actual process of packaging is like a lot of the time.  The upstream developers typically do not supply comprehensive documentation on how to build their software and it often relies on "libraries" whose documentation is also sparse, variable quality and scattered all over the internet.  I hope I'm not putting people off but I do think we need to be realistic about what is involved.

Terry.

[sling-shot]

In a curious way, learning packaging by piecing together sparse and obscure information is actually a good introduction to what the actual process of packaging is like a lot of the time.

I understand. But I am sorry I do not agree with you on this in our situation. It will work for someone who wants to learn this for a living or as a prime hobby.

As I understand our users are mostly general public and not software people. I am definitely not a software guy. The statements in this thread by posters previously shows what happens when they try packaging.

I guess a step by step guidance in the initial days to get over that crest will have them going on from then on. Hopefully

[sling-shot]

This is my version. It must have a lot of inaccuracies. Kindly correct. I intend to put this somewhere at the beginning of the packaging guide even before Neal's section

PACKAGING - A rough overview (PCLinuxOS perspective only)
---------------------------------------------------------------

Packaging is the process of converting original software/items from coders into a form which is ready for download and installation by end users.

Now the original software/items could be media (wallpapers, icons, sounds etc.) or software (binary executables, source code)
The most common use of packaging however is to convert source into installable .rpms for end users.

Software from source - Most of the software written by humans is in the form of a human readable language such as Assembly (low level), C / C++ (medium level), Python / Java (higher level or interpreted languages). However a computer will only understand instructions in machine language which is in binary form. So we need to convert the software from human readable languages to machine language. This is done by a method known generally as compiling / building.

Now this building can happen at 3 different places.
- 1. At the original author of software : Most commercial software is distributable pre-built.
- 2. At the distributor : That is what our Bacon Brigade does.
- 3. At the end user : Luckily users of PCLinuxOS do not have to do this. This is the standard method in source based distros.

So in our case the following is done.
- 1. Software is procured from source by the packager.
- 2. A virtual environment is created inside the packager's computer where this source is compiled into binary form. This environment is as close to a standard PCLinuxOS installation as possible. (?? /src/rpm/BUILD or ?? _tmppath)
- 3. A virtual installation of the created software is done in another virtual environment representative of end user. (?? /src/rpm/BUILDROOT)
- 4. The resulting files are picked out of this virtual environment and put together inside an archive and this is called a package. This will be found in /src/rpm/RPMS/i586 or x64 depending on the target.
- 5. A copy of the source code along with the .spec file used to create this package is placed in /src/rpm/SPRM. This is what is used by the maintainer of PCLinuxOS to recreate the same package and enter it into the official repository after quality control checks.

Things are slightly different when it comes to binary packages and media as they already come in compiled binary form. They mostly only need to be placed into their proper location.

[Just17]

Kind of echoes what I tried to say. If you don't already have some basic knowledge then the learning curve will be astronomical.

Yes it will be a steep learning curve but not impossible.  If you are the sort of person that enjoys the challenge of taking something that doesn't work, figuring out (by research, learning and testing) what is wrong with it and making it work then you can succeed on this learning curve and will get great satisfaction in the process.  On the other hand, if you are the sort of person that just wants to blindly follow step-by-step instructions (without understanding) and throw your hands up in the air and quit as soon as something doesn't do what it's supposed to then you will find it very hard.

Seems to me you have excluded most people I know with this division into 2.

What about all the people who want to blindly follow a step-by-step guide in the first place; get a satisfactory result which will boost their confidence and allow them to see that this is not impossible and they can achieve their goal of packaging an application?

With that small success under their belt they can move on to something a little more difficult which will maybe throw up some problems which they will then have to investigate, research and solve ....  with help of the experienced packagers .....  and when successful they get the satisfaction of another hurdle overcome.

I believe the majority of interested parties would fall into this category, and be able to try packaging under those circumstances.
Some might then have the chance to continue on the path and become experienced packagers.

It was for this very reason that I suggested something like a 10 step packaging course, starting with something simple and moving up in difficulty as the previous packages were successfully built.

There is one further suggestion I would make ...

there are a number of simple-to-build (in the whole scheme of things) packages/utilities in the repos which could not only be used as introductory examples for new packagers, but their continued maintenance might also be taken up by new packagers.

An example of such might be LiveUSB-Creator, PCLinuxOS-pvr etc etc ..... (hopefully I am not stepping on anyone's toes) .......  which could be put into a pool for new packagers to 'cut their teeth' on.

....  just some thoughts ......

In a curious way, learning packaging by piecing together sparse and obscure information is actually a good introduction to what the actual process of packaging is like a lot of the time.  The upstream developers typically do not supply comprehensive documentation with their software and it often relies on "libraries" whose documentation is also sparse, variable quality and scattered all over the internet.  I hope I'm not putting people off but I do think we need to be realistic about what is involved.

Terry.