The next step?

[rick0612]

Having just started packaging, I noticed there are PCLinuxOS specifications for everything. There is a PCLOS spec for a base system like the foundation of a house. There is a PCLOS spec for the framing. There is a PCLOS spec for the plumbing, electrical work, sheet rock and paint (libs, Build Requires, etc.). All designed to ensure we have a clean, safe environment in which to work our packaging magic.
I like specifications. Specs help give consistent results. Specs help packagers be confident they are sending good work upstream. Specs help upstream managers get their jobs done quickly. Specs help everyone involved.
The only thing I couldn't find a PCLOS spec for is a roof. A roof keeps out rain, hail, dirt and other debris (libs, utils, crap) that would mess up our clean, safe environment. A roof shouldn't leak nor fall in. People shouldn't be allowed to punch holes in the roof. It shouldn't be any old roof either; it should be a PCLOS specified roof. A roof that fits our environment and ensures it is as clean for the next package as it was for the first.
I think we should take the next step and create a roof.
A suggestion would be a thread where packagers can express ideas on how best to do this and input the way they clean up between packages. At some point, the honchos would close the thread and hash out the best PCLOS spec for a roof. Unless I missed it and there is a roof in place.
Any ideas? Or am I way off base.

Rick.

[sling-shot]

[rick0612]
Man....
Your whole post just flew over my head!

Let us get things clear:
- When you mean PCLinuxOS SPEC, do you mean the .spec file which is used to build a package or the overall specifications of a PCLinuxOS system such as where it keeps its libraries, where it keeps its man pages etc...?
- What do the analogies you have used here mean? What is roof? What is paint?
- Look through this thread - Request help with maintaining a clean testing environment - may be there is some information you are looking for there?

[kjpetrie]

Surely the roof is the repo. Only stuff in there should be installed, and therefore all libraries and utilities come from approved packages. The repo is maintained by Neal, so maybe he's part of the roof too.

We also have rkhunter to check for rootkits (though how useful it is I'm not sure - it never seems to have any updates.)

If I've misunderstood your metaphor, sorry, it isn't that clear exactly what you mean.

[Neal ManBear]

rick0612,     
Try saying that in a non-metaphorical way.     

[rick0612]

OK, so I got too clever for my own good.

The specs or specifications I refer to are the steps to set up and process a package. The Wiki specifies KDE-Minime or LXDE-Minime as the environment to use for packaging. The Wiki also specifies build steps and Dos and Don'ts, etc. Those are the specs I mean. There are others such as specifications on how to declare libs, Build requires, etc.

For the roof I meant, I feel there should be a specification for how to keep a clean system. sling-shot - In your link there are at least three ways to clean up extraneous files. My question is; is there a PCLOS specified procedure for keeping a clean system. Are the requirements the same as a clean install of KDE-Minime? If so, how does one go about achieving a clean system after packaging? Neal and company specify a procedure for packaging. I think they should go the next step and specify a PCLOS approved procedure for cleaning up.

Again, if one exists, I haven't found it. If one exists or is PCLOS approved, it should go in the Wiki.

Hope this clears things up.

[sling-shot]

For a clean environment, I believe the rsync way should be the ideal way to go.
Once you have set up a new packaging environment, just mirror it elsewhere.
After each packaging job concludes, mirror it back.
Also update the clean environment regularly and update the mirror too.

----

Realistically though, it may be enough to follow the procedure of maintaining a strict log of what is installed during a packaging job and then uninstall everything after the job. In some cases, this may remove extra packages, so make a note of them and re-add them back to bring the environment back to factory settings.

[kjpetrie]

Or you could remaster before packaging and re-install, or you could use a virtual machine and copy the virtual disc image or take a snapshot before installing the rpm and its build requirements.

There are lots of ways to do it.

[Neal ManBear]

When installing build dependencies, always answer yes to the question of creating a log. This will create a .remove file for the app you are packaging. After you have built the RPM(s), open it. You will find a list of the package(s) installed. Use apt-get remove packagename 2ndpackagename and so on to remove them. Take note of any extra packages removed, so you can reinstall them.     
Every part of pkgutils has a purpose. The .remove file part of addpkg (Install Dependencies) has the purpose of being a list of packages to remove after a build.