On Mon, Dec 27, 2004 at 02:36:24AM +0100, Kilian Krause wrote:
> Hi Enrico,
>
> Hans Ulrich Niedermann and me have started reviewing the debian package
> and put up some agenda we think should be clarified to ease packaging
> (not only on Debian).
>
> The TODO file with our questions can be found
Re,
-(snip)-
> rebootmanager is obsoleted since a long time
> (it was replaced by vshelper)
ok, fine. yet the make install or make install-distribution does still
yield it. That's nothing i would copy within the debian/rules.
> |- How should the packaging devide up the groups most convenien
* Kilian Krause ([EMAIL PROTECTED]) wrote:
> We'd appreciate if you could go through the TODO and help us with the
> open questions.
Just as another (very) interested Debian developer-
The graphviz stuff sounds new, I don't recall seeing it when I did
0.30.195.. In general I'd say either remove
* Herbert Poetzl ([EMAIL PROTECTED]) wrote:
> |- How should the packaging devide up the groups most conveniently?
>
> util-vserver-0.30.196
> util-vserver-lib-0.30.196
> util-vserver-sysv-0.30.196
> util-vserver-core-0.30.196
> util-vserver-build-0.30.196
> util-vserver-legacy-0.30.196
Good g
* Kilian Krause ([EMAIL PROTECTED]) wrote:
> > util-vserver-0.30.196
> > util-vserver-lib-0.30.196
> > util-vserver-sysv-0.30.196
> > util-vserver-core-0.30.196
> > util-vserver-build-0.30.196
> > util-vserver-legacy-0.30.196
>
> ok, we'll try to bring that to the debs. Is there a list which files
[...I will abuse Herbert's posting because it contains the TODO list...]
[EMAIL PROTECTED] (Herbert Poetzl) writes:
>> Hi Enrico,
>>
>> Hans Ulrich Niedermann and me have started reviewing the debian package
>> and put up some agenda we think should be clarified to ease packaging
>> (not only on
* Enrico Scholz ([EMAIL PROTECTED]) wrote:
> [EMAIL PROTECTED] (Herbert Poetzl) writes:
> > | * A lot of programs don't have documentation. Add man pages in DocBook?
>
> Maintainership of the man-pages will be a problem; especially in
> the current stage where features might be added or removed ve
Hi Enrico,
> > | * /etc/vserver/util-vserver-vars
>
> Please do not install 'util-vserver-vars' into /etc. There is nothing
> which can be changed at runtime across the entire toolset (binaries have
> the values statically compiled in). The file is badly named and should
> be called 'util-vserver
hi Stephen,
Am Montag, den 27.12.2004, 08:49 -0500 schrieb Stephen Frost:
> * Kilian Krause ([EMAIL PROTECTED]) wrote:
> > We'd appreciate if you could go through the TODO and help us with the
> > open questions.
>
> Just as another (very) interested Debian developer-
welcome to the troups. Feel
Hi Stephen,
> > > | * pkglibdir is /usr/lib/util-vserver instead of /var/lib/util-vserver
> >
> > ??? this is standard in autoconf packages.
>
> I was wondering a bit about this myself.. The difference between
> /usr/lib and /var/lib is pretty clear- is there stuff in util-vserver
> that modifi
Stephen Frost said:
> As I mentioned in the other thread- please don't. It doesn't make sense
> and it's really not a sane thing to do for Debian.
It just makes it more complex, with no real benefit.
I would reccomend keeping it the same 2 packages.
--
Luke Computer Science System Administrator
* Kilian Krause ([EMAIL PROTECTED]) wrote:
> > > > | * pkglibdir is /usr/lib/util-vserver instead of /var/lib/util-vserver
> > >
> > > ??? this is standard in autoconf packages.
> >
> > I was wondering a bit about this myself.. The difference between
> > /usr/lib and /var/lib is pretty clear- is
* Kilian Krause ([EMAIL PROTECTED]) wrote:
> Am Montag, den 27.12.2004, 08:49 -0500 schrieb Stephen Frost:
> > Just as another (very) interested Debian developer-
>
> welcome to the troups. Feel free to testdrive my packages and comment on
> them or send me a patch. =)
Sure, once they're to my li
On Mon, Dec 27, 2004 at 04:26:45PM +0100, Kilian Krause wrote:
> Hi Enrico,
>
> > > | * /etc/vserver/util-vserver-vars
> >
> > Please do not install 'util-vserver-vars' into /etc. There is nothing
> > which can be changed at runtime across the entire toolset (binaries have
> > the values statical
* Herbert Poetzl ([EMAIL PROTECTED]) wrote:
> On Mon, Dec 27, 2004 at 04:26:45PM +0100, Kilian Krause wrote:
> > Has so far only _one_ app been coded outside the util-vserver domain? If
> > not, i'd vote for leaving this out until someone complains.
>
> hmm, well, the thing here is that we _should
Hello
On Mon, Dec 27, 2004 at 08:57:09AM -0500, Stephen Frost wrote:
> * Herbert Poetzl ([EMAIL PROTECTED]) wrote:
> > |- How should the packaging devide up the groups most conveniently?
> >
> > util-vserver-0.30.196
> > util-vserver-lib-0.30.196
> > util-vserver-sysv-0.30.196
> > util-vserve
[EMAIL PROTECTED] (Kilian Krause) writes:
>> > | * /etc/vserver/util-vserver-vars
>>
>> Please do not install 'util-vserver-vars' into /etc.
> ...
> Yet the option to allow a relocation of the default vserver rootdir
> would be highly appreciated. (and IMHO broken if not availble at all)
The de
Kilian Krause <[EMAIL PROTECTED]> writes:
>> > | * The distclean target does also remove util-vserver.spec which is
>> > | shipped in the release tarball.
>>
>> Where is the problem? The corresponding clean-rule is autogenerated
>> by autoconf and the file can be recreated by './configure' resp
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Enrico Scholz ([EMAIL PROTECTED]) wrote:
>> [EMAIL PROTECTED] (Herbert Poetzl) writes:
>> > | * A lot of programs don't have documentation. Add man pages in DocBook?
>>
>> Maintainership of the man-pages will be a problem; especially in
>> the current
Stephen Frost <[EMAIL PROTECTED]> writes:
> Just as another (very) interested Debian developer-
>
> The graphviz stuff sounds new, I don't recall seeing it when I did
> 0.30.195.. In general I'd say either remove it or use something free to
> build it.
graphviz is used by doxygen while building
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Herbert Poetzl ([EMAIL PROTECTED]) wrote:
>> |- How should the packaging devide up the groups most conveniently?
>>
>> util-vserver-0.30.196
>> util-vserver-lib-0.30.196
>> util-vserver-sysv-0.30.196
>> util-vserver-core-0.30.196
>> util-vserver-b
[EMAIL PROTECTED] (Stephen Frost) writes:
>> > | * pkglibdir is /usr/lib/util-vserver instead of /var/lib/util-vserver
>>
>> ??? this is standard in autoconf packages.
>
> I was wondering a bit about this myself.. The difference between
> /usr/lib and /var/lib is pretty clear- is there stuff in
[EMAIL PROTECTED] (Herbert Poetzl) writes:
As there is some discussion about the package-count let me explain the
background of the packaging:
> |- How should the packaging devide up the groups most conveniently?
>
> util-vserver-core-0.30.196
Contains low-level utilities which use the linux
Hi Enrico,
Am Montag, den 27.12.2004, 23:02 +0100 schrieb Enrico Scholz:
> [EMAIL PROTECTED] (Kilian Krause) writes:
>
> >> > | * /etc/vserver/util-vserver-vars
> >>
> >> Please do not install 'util-vserver-vars' into /etc.
> > ...
> > Yet the option to allow a relocation of the default vserver
* Enrico Scholz ([EMAIL PROTECTED]) wrote:
> [EMAIL PROTECTED] (Stephen Frost) writes:
> > and that it perhaps shouldn't even be packaged at all
>
> No, things like $PACKAGE_VERSION are changing with every version and
> must be told to the single scripts. Same holds for the configured paths.
So,
* Kilian Krause ([EMAIL PROTECTED]) wrote:
> Am Montag, den 27.12.2004, 23:02 +0100 schrieb Enrico Scholz:
> > Root-directory of existing vservers is /etc/vservers/.../vdir and the
> > location for newly created vservers is based on
> > /etc/vservers/.defaults/vdirbase.
>
> thanks for the pointer.
* Hans Ulrich Niedermann ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> Putting the legacy stuff into a separate legacy package would
> help new users a lot by reducing confusion as to what is legacy and
> what is not.
Alright, then maybe a -legacy or some such package, o
On Mon, Dec 27, 2004 at 08:16:54PM -0500, Stephen Frost wrote:
> * Enrico Scholz ([EMAIL PROTECTED]) wrote:
> > [EMAIL PROTECTED] (Stephen Frost) writes:
> > > and that it perhaps shouldn't even be packaged at all
> >
> > No, things like $PACKAGE_VERSION are changing with every version and
> > mus
* Herbert Poetzl ([EMAIL PROTECTED]) wrote:
> On Mon, Dec 27, 2004 at 08:16:54PM -0500, Stephen Frost wrote:
> > Not entirely sure what to tell you about vshelper and being called by
> > the kernel... That's just an odd situation. :) Is there any
> > environment at that point, coming from *somewh
On Mon, Dec 27, 2004 at 08:28:45PM -0500, Stephen Frost wrote:
> * Hans Ulrich Niedermann ([EMAIL PROTECTED]) wrote:
> > Stephen Frost <[EMAIL PROTECTED]> writes:
> > Putting the legacy stuff into a separate legacy package would
> > help new users a lot by reducing confusion as to what is legacy an
On Mon, Dec 27, 2004 at 08:38:10PM -0500, Stephen Frost wrote:
> * Herbert Poetzl ([EMAIL PROTECTED]) wrote:
> > On Mon, Dec 27, 2004 at 08:16:54PM -0500, Stephen Frost wrote:
> > > Not entirely sure what to tell you about vshelper and being called by
> > > the kernel... That's just an odd situati
* Herbert Poetzl ([EMAIL PROTECTED]) wrote:
> On Mon, Dec 27, 2004 at 08:28:45PM -0500, Stephen Frost wrote:
> > Alright, then maybe a -legacy or some such package, or just a really
> > stern warning at the start of all the -legacy stuff saying "this is
> > legacy, you shouldn't be using it", or ju
* Herbert Poetzl ([EMAIL PROTECTED]) wrote:
> On Mon, Dec 27, 2004 at 08:38:10PM -0500, Stephen Frost wrote:
> > Ah, interesting... That means anything that's needed by vshelper that's
> > not in those paths on most systems is a candidate for being hard-coded.
> > Does much fall into this category
On Mon, Dec 27, 2004 at 08:48:43PM -0500, Stephen Frost wrote:
> * Herbert Poetzl ([EMAIL PROTECTED]) wrote:
> > On Mon, Dec 27, 2004 at 08:28:45PM -0500, Stephen Frost wrote:
> > > Alright, then maybe a -legacy or some such package, or just a really
> > > stern warning at the start of all the -leg
* Herbert Poetzl ([EMAIL PROTECTED]) wrote:
> On Mon, Dec 27, 2004 at 08:48:43PM -0500, Stephen Frost wrote:
> > Perhaps, I just don't like releasing legacy tools. How difficult is it
> > to move to the new tools? Are the 'new' vservers the 2.6 ones, and the
> > 'old' vservers the 2.4 ones, or ca
On Mon, Dec 27, 2004 at 09:05:21PM -0500, Stephen Frost wrote:
> * Herbert Poetzl ([EMAIL PROTECTED]) wrote:
> > On Mon, Dec 27, 2004 at 08:48:43PM -0500, Stephen Frost wrote:
> > > Perhaps, I just don't like releasing legacy tools. How difficult is it
> > > to move to the new tools? Are the 'new
[EMAIL PROTECTED] (Stephen Frost) writes:
>> > Alright, then maybe a -legacy or some such package, or just a really
>> > stern warning at the start of all the -legacy stuff saying "this is
>> > legacy, you shouldn't be using it", or just don't distribute it at all
>> > (my personal favorite).
>>
[EMAIL PROTECTED] (Stephen Frost) writes:
>> > and that it perhaps shouldn't even be packaged at all
>>
>> No, things like $PACKAGE_VERSION are changing with every version and
>> must be told to the single scripts. Same holds for the configured paths.
>
> So, it's used by scripts *and* is compile
Herbert Poetzl <[EMAIL PROTECTED]> writes:
> On Mon, Dec 27, 2004 at 09:05:21PM -0500, Stephen Frost wrote:
>> * Herbert Poetzl ([EMAIL PROTECTED]) wrote:
>> > On Mon, Dec 27, 2004 at 08:48:43PM -0500, Stephen Frost wrote:
>> > > syslogd and klogd are seperate packages already, the problem is tha
On Mon, 27 Dec 2004, Stephen Frost wrote:
> * Enrico Scholz ([EMAIL PROTECTED]) wrote:
> > * execve(2) is more efficiently than execvp(3)
>
> Is there something in here that actually would notice from such a
> change? Seriously, is there *really* some benefit here for an end user
> or is this ju
* Enrico Scholz ([EMAIL PROTECTED]) wrote:
> [EMAIL PROTECTED] (Stephen Frost) writes:
> > So, it's used by scripts *and* is compiled into programs?
>
> Yes; e.g.
I believed you, I just find it kind of ugly. :)
> > I'm thinking it might go in /usr/share/util-vserver then, since it's
> > not syst
* Herbert Poetzl ([EMAIL PROTECTED]) wrote:
> On Mon, Dec 27, 2004 at 09:05:21PM -0500, Stephen Frost wrote:
> > Again, a Debian util-vserver package couldn't do that due to sane policy
> > issues. It'd be nice if we didn't have to worry about it because the
> > kernel/vserver patch took care of i
* Hans Ulrich Niedermann ([EMAIL PROTECTED]) wrote:
> And you can even do that disabling cleanly and automatically if you
> install your guest systems with a virtual klogd instead of the
> standard one which contains nothing but
>
> Provides: linux-kernel-log-daemon
> Conflicts: li
[EMAIL PROTECTED] (Stephen Frost) writes:
>> [... absolute paths vs. resolution with $PATH ...]
>> using execvp(3) would mean:
>> * trusting in $PATH that it contains the wanted path (this has to deal
>> with packaging philosophies also which expect all 3rd party apps
>> under /opt/) --> /etc
On Tue, Dec 28, 2004 at 05:23:18PM +0100, Enrico Scholz wrote:
> [EMAIL PROTECTED] (Stephen Frost) writes:
>
> >> [... absolute paths vs. resolution with $PATH ...]
> >> using execvp(3) would mean:
> >> * trusting in $PATH that it contains the wanted path (this has to deal
> >> with packaging p
On Tue, Dec 28, 2004 at 11:23:03AM +0100, Hans Ulrich Niedermann wrote:
> Herbert Poetzl <[EMAIL PROTECTED]> writes:
>
> > On Mon, Dec 27, 2004 at 09:05:21PM -0500, Stephen Frost wrote:
> >> * Herbert Poetzl ([EMAIL PROTECTED]) wrote:
> >> > On Mon, Dec 27, 2004 at 08:48:43PM -0500, Stephen Frost
Herbert Poetzl <[EMAIL PROTECTED]> writes:
> On Tue, Dec 28, 2004 at 11:23:03AM +0100, Hans Ulrich Niedermann wrote:
[ Vserver guest systems are different from normal systems, and thus
require special handling services for klogd and hardware access.
Herbert Poetzl says "just disable the servi
On Tue, Dec 28, 2004 at 08:08:34PM +0100, Hans Ulrich Niedermann wrote:
> Herbert Poetzl <[EMAIL PROTECTED]> writes:
>
> > On Tue, Dec 28, 2004 at 11:23:03AM +0100, Hans Ulrich Niedermann wrote:
>
> [ Vserver guest systems are different from normal systems, and thus
> require special handling s
Hi Enrico,
Am Dienstag, den 28.12.2004, 03:49 +0100 schrieb Enrico Scholz:
> >> [ ... util-vserver.spec ...]
> >> > Sounds like maybe it shouldn't be shipped in the release tarball
> >> > then..
> >>
> >> No, it must be shipped. Else 'rpmbuild -ta util-vserver...tar.bz2' would
> >> not work anymo
Hi Herbert,
Am Mittwoch, den 29.12.2004, 00:01 +0100 schrieb Herbert Poetzl:
> > > chkconfig --del network
> > >
> > > and it removes all the links from the various runlevels
> > > so that 'network' isn't started anymore ...
> >
> > The problem is that as soon as the next update to the "network
[EMAIL PROTECTED] ("Kilian Krause") writes:
>> >> [ ... util-vserver.spec ...]
>> > Hrmpf. Then can we just not delete it in make clean?
>>
>> I will think about this; but I still do not understand the problem
>> there.
>
> very easy to tell. You're talking about "what configure builds, make
> c
Hi Enrico,
Am Donnerstag, den 30.12.2004, 01:13 +0100 schrieb Enrico Scholz:
> [EMAIL PROTECTED] ("Kilian Krause") writes:
>
> >> >> [ ... util-vserver.spec ...]
> >> > Hrmpf. Then can we just not delete it in make clean?
> >>
> >> I will think about this; but I still do not understand the prob
* Kilian Krause ([EMAIL PROTECTED]) wrote:
> well, it doesn't forcibly re-activate them. Just update-rc.d has a logic
> that when *NONE* of the runlevels has any symlink for either
> S??$SERVICENAME or K??$SERVICENAME then it'll try to create them for
> it's thinking it's being installed for the fi
53 matches
Mail list logo
