Re: [gentoo-user] Re: rpm or deb package installs

2015-02-22 Thread Tom H
On Sat, Feb 14, 2015 at 1:30 AM, Alan McKinnon alan.mckin...@gmail.com wrote:

 rpms and debs are both cpio files so the easy way is to unpack them and
 see what's going on:

 rpm2cpio name.rpm | cpio -iv --make-directories
 dpkg -x somepackage.deb ~/temp/

For deb packages, you can use binutils' ar; there's no need for dpkg.
(IIRC, if you use rpm2tar, you don't need rpm installed unlike
rpm2cpio, but I'm not 100% sure.)



Re: [gentoo-user] Re: rpm or deb package installs

2015-02-22 Thread R0b0t1
 For deb packages, you can use binutils' ar; there's no need for dpkg.
 (IIRC, if you use rpm2tar, you don't need rpm installed unlike
 rpm2cpio, but I'm not 100% sure.)


You are right, rpm2targz doesn't require rpm to be installed. I found
I already had it installed yesterday (via libreoffice).



Re: [gentoo-user] Re: rpm or deb package installs

2015-02-13 Thread Bill Kenworthy
On 14/02/15 05:08, James wrote:
 Alan McKinnon alan.mckinnon at gmail.com writes:
 
 
...
 Any special reason why you don't instead download the sources and build
 them yourself with PREFIX=/usr/local ?
 
 Lots of errant codes flying everywhere so you have to pull a code audit
 to see what's in the raw tarballs before building. That takes way too much
 time. I'm working on setting up several more workstations for coding to
 isolate them from my main system. This approach you suggest is: error prone,
 takes too much time, and I'm lazy and sometimes even stupid.
 I need a structure methodology to be a one man extreme_hack_prolific
 system that prevents me from doing stupid things, whilst I'm distracted.
 

 
 

rpm is just a wrapper around a an archive with instructions on how to
build and or install it.  I have more experience with rpm's but I
believe debs are the same.  Just unwrap your .rpm/.deb file of choice
and install it manually (the binaries/code are usually in a zip inside
the rpm).  You should in most cases also be able to get a source rpm
(which I suspect you are talking about anyway, but binaries do work deps
permitting.

you can install rpm and then install your package via rpm - seem to
remember doing this with .debs somehow too.  deps are a problem but
usually workable.

and why set up a workstation? - this sort of thing is tailor made for
vm's.  Create a base for your experiments with essential packages,
settings etc, snapshot it (golden master) and then throwaway-restore
when finished with that iteration.

There are package managers besides gentoo/protage that can do a source
build/install and track the files on gentoo - though portage will not
know about it (rpm is one :)

and lastly, what do mean error prone? - to me a manual install is the
ONLY way you can build a proper ebuild that catches most of the
problems.  In the (admittedly few) ebuilds I have done an occasional
human error is nothing compared to system problems for a difficult package.

BillK





Re: [gentoo-user] Re: rpm or deb package installs

2015-02-13 Thread Neil Bothwick
On Fri, 13 Feb 2015 21:08:55 + (UTC), James wrote:

  I doubt dpkg and rpm aren't going to be much use to you, unless you
  really want to run two package managers. Besides, both are not
  especially useful with the front ends apt* and yum.  
 
 I'd just use those to unpackage and maybe preprocess some of the codes.
 
 Agreed. I do not want a full blown deb or rpm package manager just
 a way to install and evaluate some of those codes before beginning a
 more arduous  and comprehensive task.

In that case you ware deb2targz or rpm2targz to convert the package to a
tarball. then you can unpack it and inspect the contents.


-- 
Neil Bothwick

If it ain't broke, break it and charge for repair.


pgpSpSg0cOcF0.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] Re: rpm or deb package installs

2015-02-13 Thread Alan McKinnon
On 13/02/2015 23:08, James wrote:
 Alan McKinnon alan.mckinnon at gmail.com writes:
 
 
 I doubt dpkg and rpm aren't going to be much use to you, unless you
 really want to run two package managers. Besides, both are not
 especially useful with the front ends apt* and yum.
 
 I'd just use those to unpackage and maybe preprocess some of the codes.
 
 Agreed. I do not want a full blown deb or rpm package manager just
 a way to install and evaluate some of those codes before beginning a more
 arduous  and comprehensive task. Maybe I should just put up a RH/centos box
 and evaluate codes there. It seems *everything* I want to test and look at
 in the cluster and hpc world, as a rpm or deb package; so I'm looking for a
 time saver, to surf thru the myriad of codes I'm getting; many look very
 cool  from the outside, but once I run them, they are pigs...
 
 Then a slick way to keep them secure and clean it out. Maybe I need chroot
 jails too? I spend way to much time managing codes rather than I do actually
 writing code. I feel confused often and cannot seem to master this
 git_thingy I have not code seriously in a long time and now it is
 becoming an obsession, but the old ways are draining my constitutional
 powers.


I see you are doing more than I thought you were doing :-)

rpms and debs are both cpio files so the easy way is to unpack them and
see what's going on:

rpm2cpio name.rpm | cpio -iv --make-directories
dpkg -x somepackage.deb ~/temp/

Considering the size of what you are doing, you are probably better off
running a Centos and Debian system to evaluate the code and discard the
rubbish. Once you've isolated the interesting ones, you can evaluate
them closer and maybe write ebuilds for them.




 
 
 Any special reason why you don't instead download the sources and build
 them yourself with PREFIX=/usr/local ?
 
 Lots of errant codes flying everywhere so you have to pull a code audit
 to see what's in the raw tarballs before building. That takes way too much
 time. I'm working on setting up several more workstations for coding to
 isolate them from my main system. This approach you suggest is: error prone,
 takes too much time, and I'm lazy and sometimes even stupid.
 I need a structure methodology to be a one man extreme_hack_prolific
 system that prevents me from doing stupid things, whilst I'm distracted.
 
 
 Maybe I should just put up a VM resources on the net, blast tons
 of tests thru the vendors hardware and let them worry about the
 security ramifications?  Some of it is these codes are based on 'functional
 languages' and I just do not trust what I do not fully understand. Stuff
 (files etc) goes everywhere and that makes me cautiously nervous. I have
 /usr/local for manual work and /usr/local/portage for ovelays (layman) but
 it's becoming a mess. There where to I put the work effort that is a  result
 from repoman. Those codes seem to be parallel projects often
 when the code I'm evaluating needs to be cleaned up or extend to properly
 test. Furthermore I have a growing collection of file that result
 from kernel profiling via  trace-cmd, valgrind, systemtap etc etc.
 As soon as I delete something, I need to re-generated it for one
 reason or another.. I just hope that this repo.conf effort
 helps be get more structurally organized?  
 
 
 Did you see/test 'travis-ci' yet? [1] I'm not sure it's the same
 on github [2] but some of the devs are using it on github. 
 
 
 
 James
 
 [1] http://docs.travis-ci.com/
 
 [2] https://github.com/travis-ci/travis-ci
 
 
 
 
 
 
 
 
 


-- 
Alan McKinnon
alan.mckin...@gmail.com