git package manager

Jonathan_R · September 2, 2011, 6:23pm

My question is direct but not simple. How hard would it be to make a git package manager? How plausable would this be?
Thoughts?
Pros/Cons?

DenverD · September 2, 2011, 7:20pm

On 09/02/2011 06:26 PM, Jonathan R wrote:
>
> My question is direct but not simple.

hmmmm, may be direct but not crystal clear to me . . .

> How hard would it be to make a git package manager?

(like) do you mean to use git to replace the YaST software management
module for openSUSE? (or as a generic linux wide package management
system to replace (say) RPM, yum, apt, etc?)

> How plausable would this be?

doesn’t Gentoo already use git as a package management system?

> Thoughts? Pros/Cons?

i think the speed advantage of git would be lost since openSUSE packages
are generally handled as executables (and so much smaller than the much
larger source tree [where git’s speed is neat-o])…

but, there is a good chance everything i wrote makes no sense, since i
admit up front i’m not certain where your question is headed…

–
DD
url=http://dilbert.com/strips/2011-08-31/smart Dilbert

hendersj · September 2, 2011, 7:29pm

On Fri, 02 Sep 2011 16:26:02 +0000, Jonathan R wrote:

> My question is direct but not simple. How hard would it be to make a git
> package manager?

How hard is probably not the right question to ask. I’d probably start
by asking if it was a good fit.

> How plausable would this be? Thoughts?
> Pros/Cons?

Source code version control software is really good for dealing with
textual information; not so good at dealing with binary information.

git is designed to do version control for source code. A git-like system
might be an interesting idea, but I don’t know that git itself is the
right tool for the job, since it wasn’t designed to handle large amounts
of binary data.

But I do like the idea of a git-like distributed system for package
repository storage.

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

ab · September 2, 2011, 7:53pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think along with Jim and DenverD’s responses I would echo the obvious
question:

Why? There must be some feature of git that you want and knowing what
that is (the “business case” if you will) would help answer whether one
technology or another can handle this in a desirable way.

Good luck.

Want to yell at me in person?
Come to BrainShare 2011 in October: http://tinyurl.com/brainshare2011
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOYRfxAAoJEF+XTK08PnB5pmMP/2ysXem3iXJrb0uFDU1ZuqeR
+o5w+AqvBDkLhTWFzhEBddtyT3Z7kVP0BZaJ5dPpzQR8snOcEyUztFhT5f10/0LA
LZW2HTDImeC3Ss0YP72XSGqcEu14D1nxTtyBEXaIQ1GgzxD1mVJZkE5TQeojet2v
3BRBODjqGiAEoxQ27mCMYBQQe3ebihx4vWrsGMG17hHi0EPCwbfViQrCIFJLzu37
ZZVp3rzL4rrRZEACLtsWDajeQpXQQcKl8MCTlSKD9nZ7x3PNBQSEuYvTRPit+aEV
PsYbalW51+C4X+ljRjoLSmjlvlsgtDOv4HpP+HXB9UgBnwxH6JZ9TBrCzr9zuhYq
OpAp2s7Dgxhi3w+HVzNsSUIhdAwQLCFvcGfVwDTkrzMYmGe9YpErDA1nCuy35oQq
BU8n46YKN8bixwzgOAyJ6Oq8i0DyMYSkXhvO6OVWdzHOfpgmpRU53MLtW2K+0yt0
bCaWHZpW/V0Alh6SBTSovpsdogyqYfN8FNLFRixc1OlvOdGzlC27RtHh6FIBnP/r
DNxaHP5zbgg4BRRBznYsjsLvB1oDSkOkhf9tTo8Uro8KLJAdzqnsUfScp7Jzkztx
Gy3o3GvZvSgVWltjDIcitv4A2MGgbdZDNofGkf1Gc/GjqB3WfxboqkBOAoszTCqY
QTd/OnVs5pyyBZZFGoCG
=71Kk
-----END PGP SIGNATURE-----

malcolmlewis · September 2, 2011, 8:22pm

Hi
Probably a better fit would be git2spec application like cpanspec one
of the problems is git repo’s vary on what tools the developer is using
to build something. Trust me it varies from nothing, to a nice error
free build…

git clone
check the build requires
check the git version


git checkout remotes/origin/HEAD

Clean out the git


rm -rf .git
find . -name .git* -exec rm {} \;

Prepare tarball


tar xjf <name>.git<YYYYMMDD>.tar.bz2

Build up a spec file to used with osc or rpmbuild

Using osc and the build service creates its own build environment so
your host system isn’t filled up with development stuff (and ensuing
updates).

Then you come to all the additional checks that are present in OBS with
brp and rpmlint reports which don’t get tested for when building
manually. How would you handle a <name>.desktop install for instance?
Things compiled without rpm optflags, 64bit portability, non-return’s
etc… the list goes on.

I suggest you see what cpanspec can do, it should give you some ideas?

–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.4 (x86_64) Kernel 2.6.37.6-0.7-desktop
up 3 days 1:24, 4 users, load average: 0.28, 0.14, 0.14
GPU GeForce 8600 GTS Silent - Driver Version: 280.13

Jonathan_R · September 2, 2011, 8:43pm

Yes git is for source code and not binary.
Yes I would love to see it replace rpm/deb (comparing yum and apt and such to rpm doesn’t work. They are tools that sit on top of rpm or deb.)
I would think that in some ways it would be faster. Say for example, once yu have the system installed, updating a small bit of code, a delta, a patch type of thing, should be faster. The initial bit might be slower, but in the long run it should be faster…I would think.

ab · September 2, 2011, 9:50pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

RPMs currently have “patch RPMs” that only apply differences, though
they may be binary differences vs. the two characters of text that
implemented a change, in cases where the code is compiled. What you’re
proposing is a nice idea, especially in a world of code that is mostly
uncompiled except at runtime (scripts). In theory binary diffs could
work as well but there would be a lot to work out for this to be
perfect. I’m also not sure how great git would be at managing packages
of all sorts coming together that had never meant to live together
before. RPM (and DEB I’m sure) handles these types of situations nicely
warning about conflicts where I do not know that git would. Anyway,
check out how your idea compares with patch RPMs to see if there is a
need still considering their existence. If so, perhaps there are tricks
to be learned in the RPM world from the git code.

Anyway, just my initial thoughts. Yours are more creative and I’d
recommend keeping them coming.

Want to yell at me in person?
Come to BrainShare 2011 in October: http://tinyurl.com/brainshare2011
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOYTNtAAoJEF+XTK08PnB5QNgP/07os+cj9SiDg11j3HFERA8S
ODgXoAaGGB7rMTARnsG4T+OyGBb6fQkcbhli9u4EZcIqQNojmZJpIwPc62eZEAUO
VmeHFRBjFRe/175UBpMD/sDLqs/T47vjmT3VVaY0d0DJC3EMEQGpmUdzxLxVrD3t
K/UOb1JJHFQY1o/l4+fom+UQ6+XIx/TvoqHrcGMOASSK3YqWdYobelJ2dFXU05ig
vRtNZHlmYxbZDdybdDNDPduCv/GpJk9nCM4jVmk4RODR7MJSJ7D1vgNb5d90JGXp
HHAvuRML8gPmr3r5NgyJ1eNTzjdUPLQvLm9azP68giQJPohNMO1wyaAoEzumTQNP
ZlZ5T7ce0/BsxNKM+abeOmGfGq2a0ViIyAIMMeKF5JvFYVHI3iUHFquB4bybKYhI
n4LCl7hu3QCMmrWljxo6+emICsszZUrmtebCpGTOQTH7oAcEK124IAUApjyYkeZt
F5y/jSuRuC7RwRQ2+8wlGWKx9YlOkqJEYZnmwvLzPZV3zLvU+pVXEkaw3okeBv+K
3yhcPXjcqQNWAD9ChcXN0yA1sutgEVmVrIfoXidplws9Bhe7F75cSmAwZO5+fHh8
WPtUS4OI5PomuTd0pS3LJKjYqGgzFGvU0wk/cfFCmD9zB5NRvmfvCypRQa0XAtTp
EmW6T3xANTUYSb3ZANj7
=mD6+
-----END PGP SIGNATURE-----

hendersj · September 2, 2011, 11:57pm

On Fri, 02 Sep 2011 18:46:02 +0000, Jonathan R wrote:

> Yes git is for source code and not binary. Yes I would love to see it
> replace rpm/deb (comparing yum and apt and such to rpm doesn’t work.
> They are tools that sit on top of rpm or deb.) I would think that in
> some ways it would be faster. Say for example, once yu have the system
> installed, updating a small bit of code, a delta, a patch type of thing,
> should be faster. The initial bit might be slower, but in the long run
> it should be faster…I would think.

If you based it on source code, though, you’d have to compile the code at
the receiving machine’s end - which on some systems could be quite slow,
and installation failures could be difficult to track down (dependency
tracking, for example).

Jim

Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

Jonathan_R · September 3, 2011, 9:24pm

hendersj:

On Fri, 02 Sep 2011 18:46:02 +0000, Jonathan R wrote:

> Yes git is for source code and not binary. Yes I would love to see it
> replace rpm/deb (comparing yum and apt and such to rpm doesn’t work.
> They are tools that sit on top of rpm or deb.) I would think that in
> some ways it would be faster. Say for example, once yu have the system
> installed, updating a small bit of code, a delta, a patch type of thing,
> should be faster. The initial bit might be slower, but in the long run
> it should be faster…I would think.

If you based it on source code, though, you’d have to compile the code at
the receiving machine’s end - which on some systems could be quite slow,
and installation failures could be difficult to track down (dependency
tracking, for example).

Jim

Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at openSUSE Forums FAQ

I would think that would be the job of the package manager. There may even be a way to make it binary.

hendersj · September 4, 2011, 5:02am

On Sat, 03 Sep 2011 19:26:02 +0000, Jonathan R wrote:

> I would think that would be the job of the package manager. There may
> even be a way to make it binary.

I think I’ve lost you…

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

Jonathan_R · September 6, 2011, 4:55pm

Actually, you didn’t loose me. I was just thinking of other ways to accomplish things with a git package manager. A binary git package manager, so on and so forth.

hendersj · September 6, 2011, 8:47pm

On Tue, 06 Sep 2011 14:56:03 +0000, Jonathan R wrote:

> Actually, you didn’t loose me. I was just thinking of other ways to
> accomplish things with a git package manager. A binary git package
> manager, so on and so forth.

Then I guess it’s all good.

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C