tapper-pm-devel

[Tapper-pm-devel] package format

[Jason K. <jas...@gm...>]

I think we should use a source-based package format, and compile it on 
each system, sort of like gentoo's portage. If this package manager 
won't be tied to any one distro, it would be a major headache to compile 
binaries for each and every platform. It'll need some sort of config 
file put into the tarball, to specify different things.

Personally, I prefer to follow the Linux Kernel 
Documentation/CodingStyle rather than the GNU, but I will work with 
either it doesn't really matter. I think it's best to have some kind of 
coding style guidelines.

If we carefully plan and split up tasks in tapperd by function, and 
individually work on the functions, then I think working on together 
would be fine. CVS seems like a little bit overkill, but we could use it 
I guess... though I'd prefer not.

Just my initial thoughts,

-- 
jason kielpinski

Re: [Tapper-pm-devel] package format

[Dag R. S. <con...@du...>]

Jason Kielpinski wrote:
> I think we should use a source-based package format, and compile it on 
> each system, sort of like gentoo's portage. If this package manager 
> won't be tied to any one distro, it would be a major headache to compile 
> binaries for each and every platform. It'll need some sort of config 
> file put into the tarball, to specify different things.
Oh, the whole concept of tapper is to attempt creating a binary based package manager. Sure this has been done before.
But not with "extentions", which are basically binary rdiff patches. Sure it will be a bit painful at times before we figure it all out.
On the other hand, those who wont try certainly wont achieve anything ;)
Perhaps it's never been done because its practically impossible, or perhaps because people assume it is.
I'm pretty certain in can be done, and that's what we're going to find out.

In many respects, if the package maintainers does a wonderful job for each and every package, and the basic system
is layed out intelligently; this is the holy grail of package management if you ask me.
No waiting for (virtually) endless builds over and over again, but still enabling quasi-buildtime optimization.
> 
> Personally, I prefer to follow the Linux Kernel 
> Documentation/CodingStyle rather than the GNU, but I will work with 
> either it doesn't really matter. I think it's best to have some kind of 
> coding style guidelines.
> 
Sounds fine by me. ;)
> If we carefully plan and split up tasks in tapperd by function, and 
> individually work on the functions, then I think working on together 
> would be fine. CVS seems like a little bit overkill, but we could use it 
> I guess... though I'd prefer not.
> 
Yeah, perhaps CVS is overkill. I don't feel very strongly for these issue, whatever works out I say!
> Just my initial thoughts,
> 


-- 

Cheers,
Dag Rune Sneeggen(ni...@du...)
---

Tapper Package Manager (http://sourceforge.net/projects/tapper-pm/) --> Do you want to miss the fun? :o

Re: [Tapper-pm-devel] package format

[Asheley L. <jun...@gm...>]

1. Use of source compiling instead of package system.
I feel that Gentoo is already doing a good job at source compilation. This
would offer nothing new IMHO. A multi version package system though is
something new and something administrators could use. The current philosoph=
y
of major distributors is to simple compile all functions into there package=
s
making them blotted and more difficult to administer and secure. The idea o=
f
the power and easy of apt-get/RPM with the advanced controls of gentoo is a
new concept.

2. CVS use
I think we should use it. As in all open source projects, new developers
will start to come on board. Patches will be developed by outsiders and be
submitted for insertion into the code base. I think CVS is necessary to the
growth and expandability of the project.

Shawn

On 10/13/05, Dag Rune Sneeggen <con...@du...> wrote:
>
> Jason Kielpinski wrote:
> > I think we should use a source-based package format, and compile it on
> > each system, sort of like gentoo's portage. If this package manager
> > won't be tied to any one distro, it would be a major headache to compil=
e
> > binaries for each and every platform. It'll need some sort of config
> > file put into the tarball, to specify different things.
> Oh, the whole concept of tapper is to attempt creating a binary based
> package manager. Sure this has been done before.
> But not with "extentions", which are basically binary rdiff patches. Sure
> it will be a bit painful at times before we figure it all out.
> On the other hand, those who wont try certainly wont achieve anything ;)
> Perhaps it's never been done because its practically impossible, or
> perhaps because people assume it is.
> I'm pretty certain in can be done, and that's what we're going to find
> out.
>
> In many respects, if the package maintainers does a wonderful job for eac=
h
> and every package, and the basic system
> is layed out intelligently; this is the holy grail of package management
> if you ask me.
> No waiting for (virtually) endless builds over and over again, but still
> enabling quasi-buildtime optimization.
> >
> > Personally, I prefer to follow the Linux Kernel
> > Documentation/CodingStyle rather than the GNU, but I will work with
> > either it doesn't really matter. I think it's best to have some kind of
> > coding style guidelines.
> >
> Sounds fine by me. ;)
> > If we carefully plan and split up tasks in tapperd by function, and
> > individually work on the functions, then I think working on together
> > would be fine. CVS seems like a little bit overkill, but we could use i=
t
> > I guess... though I'd prefer not.
> >
> Yeah, perhaps CVS is overkill. I don't feel very strongly for these issue=
,
> whatever works out I say!
> > Just my initial thoughts,
> >
>
>
> --
>
> Cheers,
> Dag Rune Sneeggen(ni...@du...)
> ---
>
> Tapper Package Manager (http://sourceforge.net/projects/tapper-pm/) --> D=
o
> you want to miss the fun? :o
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Tapper-pm-devel mailing list
> Tap...@li...
> https://lists.sourceforge.net/lists/listinfo/tapper-pm-devel
>