On Wed, 20 Aug 2003, Pablo wrote:
hi Guenter!
I wrote to Yves to find more about putting his externals into cvs and about compiling pidip w/o support for liblame.
About having one or several source packages i'm not very sure.. it's clear we need that for small externals, but for the big ones it could be a bit annoying, also i don't like the versioning scheme you are using... for example your debian package for pdp has version 00.20030718-5 while it'd be much nicer if it said 0.9 as that's the version for pdp.
Exactly. Thats why I want the big packages that do "something else" as separate source packages, thats the only way to do proper versioning.
The plan is to have one "pd-externals" package, which will hold all the small externals, and make additional modules for the others.
currently this would be: - pdp - flext (together with the externals written with flext) - zexy - cyclone - unauthorized (just saw that they are in there)
The best would be to move all the other deeper into the hierarchy:
externals\ \externals \flext.. (with footils ..) \pdp (with pidip .. ?) \miXed \unauthorized \zexy
i think big packets that are actualizad constantly like pdp and pidip for example might go into a different source package w/o much problem and definitely their version should read like the real one. anyway i don't know if having a very big source package is a big problem. i'm starting to mess with it.
i'm looking to integate pdp into your source package for the moment, i hope to have it finished soon. i have used cvs several times, but i want to familiarize with your structure. also i'm not sure if i should try to actualize it or just delete the old folder and create a new one with the new version.
As Tom doesn't seem to be actively working with the CVS you can do as you like. (You can't delete the folder itself anyhow, but only its contents).
this is it for the moment...
ok, cool, finally I think we should move our discussions to pd-devel .. (which I did with this message)
Guenter
pablo
On Thursday, Aug 21, 2003, at 04:25 America/New_York, guenter geiger wrote:
On Wed, 20 Aug 2003, Pablo wrote:
hi Guenter!
I wrote to Yves to find more about putting his externals into cvs and about compiling pidip w/o support for liblame.
About having one or several source packages i'm not very sure.. it's clear we need that for small externals, but for the big ones it could be a bit annoying, also i don't like the versioning scheme you are using... for example your debian package for pdp has version 00.20030718-5 while it'd be much nicer if it said 0.9 as that's the version for pdp.
Exactly. Thats why I want the big packages that do "something else" as separate source packages, thats the only way to do proper versioning.
The plan is to have one "pd-externals" package, which will hold all the small externals, and make additional modules for the others.
currently this would be:
- pdp
- flext (together with the externals written with flext)
- zexy
- cyclone
- unauthorized (just saw that they are in there)
The best would be to move all the other deeper into the hierarchy:
externals\ \externals \flext.. (with footils ..) \pdp (with pidip .. ?) \miXed \unauthorized \zexy
I would support this structure as long as all of the dependencies are sure to work on all of the various debian platforms. I think that the original idea makes sense when considering all of the platforms that Debian runs on (having pd-externals be a package of all externals that don't have dependencies beyond libc, and other externals with more dependencies would be grouped into other packages). Otherwise, someone on a less popular platform could be prevented from easily using all of the externals if one dep is missing.
.hc
On Mon, 25 Aug 2003, Hans-Christoph Steiner wrote:
externals\ \externals \flext.. (with footils ..) \pdp (with pidip .. ?) \miXed \unauthorized \zexy
I would support this structure as long as all of the dependencies are sure to work on all of the various debian platforms. I think that the original idea makes sense when considering all of the platforms that Debian runs on (having pd-externals be a package of all externals that don't have dependencies beyond libc, and other externals with more dependencies would be grouped into other packages). Otherwise, someone on a less popular platform could be prevented from easily using all of the externals if one dep is missing.
The old structure has the big disadvantage that all of the parts have to be stable at the same time. This is almost imposslibe, so I think restructuring is a must.
Guenter