* Re: [PATCH] tools: Improve make deb
2012-04-24 13:46 ` George Dunlap
@ 2012-04-24 13:56 ` George Dunlap
2012-04-24 14:22 ` Ian Campbell
2012-04-24 15:54 ` Ian Jackson
2012-04-24 14:02 ` Dario Faggioli
2012-04-24 14:20 ` Ian Campbell
2 siblings, 2 replies; 11+ messages in thread
From: George Dunlap @ 2012-04-24 13:56 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, fantonifabio@tiscali.it
On Tue, Apr 24, 2012 at 2:46 PM, George Dunlap <dunlapg@umich.edu> wrote:
> On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>> - Add conffiles to manage main config files on package update
>>> - Add/remove of main services (xencommons, xendomains)
>>
>> I don't have any particular objection to doing this but I think we need
>> to be clear about what the purpose of Xen's "deb" target is.
>>
>> It is intended as a convenience to developers (and perhaps some subset
>> of users), to allow them to do a reasonably clean "uninstall" of Xen
>> installed from source. It is not really intended to provide anything
>> more than that.
>>
>> In particular the packages may not be fully policy compliant and we do
>> not plan to support things such as upgrades and the like. It also may
>> well be the case the installing the .deb is not sufficient to get a
>> working Xen system (i.e. you may still need to do much of the manual
>> configuration which is needed if you are building from source). If users
>> want a good, well supported package, well integrated, policy compliant
>> package for their distro then they should get it from the experts --
>> i.e. from the distro.
>>
>> I'm just concerned that with these patches you may be trying to turn
>> this simple convenience functionality into something which you think is
>> suitable for end user consumption, which is something we need to think
>> carefully about since there is a maintenance (and expectation) burden
>> imposed by doing that.
>
> I think in an ideal world, "make deb" (or "make rpm") would be used by
> exactly the same people who at the moment do "make install" -- that
> is, fairly technical end-users who have the knowledge to muck about
> with their system; they need to take the responsibility to not shoot
> themselves in the foot (or to bandage it up properly if they do). I
> think it's fairly likely that this will be the case, as long as we set
> the expectations properly in the documentation and so on.
[Remembering to cc everyone]
Is there a way to add a banner to the install / package description
saying something like, "Warning: This is a custom build of Xen; it is
not an officially supported Debian package. Please do not
distribute." Would that make sure no one is confused about the
resulting package?
-George
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tools: Improve make deb
2012-04-24 13:56 ` George Dunlap
@ 2012-04-24 14:22 ` Ian Campbell
2012-04-24 15:54 ` Ian Jackson
1 sibling, 0 replies; 11+ messages in thread
From: Ian Campbell @ 2012-04-24 14:22 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, fantonifabio@tiscali.it
On Tue, 2012-04-24 at 14:56 +0100, George Dunlap wrote:
> On Tue, Apr 24, 2012 at 2:46 PM, George Dunlap <dunlapg@umich.edu> wrote:
> > On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >>> - Add conffiles to manage main config files on package update
> >>> - Add/remove of main services (xencommons, xendomains)
> >>
> >> I don't have any particular objection to doing this but I think we need
> >> to be clear about what the purpose of Xen's "deb" target is.
> >>
> >> It is intended as a convenience to developers (and perhaps some subset
> >> of users), to allow them to do a reasonably clean "uninstall" of Xen
> >> installed from source. It is not really intended to provide anything
> >> more than that.
> >>
> >> In particular the packages may not be fully policy compliant and we do
> >> not plan to support things such as upgrades and the like. It also may
> >> well be the case the installing the .deb is not sufficient to get a
> >> working Xen system (i.e. you may still need to do much of the manual
> >> configuration which is needed if you are building from source). If users
> >> want a good, well supported package, well integrated, policy compliant
> >> package for their distro then they should get it from the experts --
> >> i.e. from the distro.
> >>
> >> I'm just concerned that with these patches you may be trying to turn
> >> this simple convenience functionality into something which you think is
> >> suitable for end user consumption, which is something we need to think
> >> carefully about since there is a maintenance (and expectation) burden
> >> imposed by doing that.
> >
> > I think in an ideal world, "make deb" (or "make rpm") would be used by
> > exactly the same people who at the moment do "make install" -- that
> > is, fairly technical end-users who have the knowledge to muck about
> > with their system; they need to take the responsibility to not shoot
> > themselves in the foot (or to bandage it up properly if they do). I
> > think it's fairly likely that this will be the case, as long as we set
> > the expectations properly in the documentation and so on.
>
> [Remembering to cc everyone]
>
> Is there a way to add a banner to the install / package description
> saying something like, "Warning: This is a custom build of Xen; it is
> not an officially supported Debian package. Please do not
> distribute." Would that make sure no one is confused about the
> resulting package?
tools/misc/mkdeb can inject whatever it likes into the description.
Ian.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tools: Improve make deb
2012-04-24 13:56 ` George Dunlap
2012-04-24 14:22 ` Ian Campbell
@ 2012-04-24 15:54 ` Ian Jackson
1 sibling, 0 replies; 11+ messages in thread
From: Ian Jackson @ 2012-04-24 15:54 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, Ian Campbell, fantonifabio@tiscali.it
George Dunlap writes ("Re: [Xen-devel] [PATCH] tools: Improve make deb"):
> [Remembering to cc everyone]
>
> Is there a way to add a banner to the install / package description
> saying something like, "Warning: This is a custom build of Xen; it is
> not an officially supported Debian package. Please do not
> distribute." Would that make sure no one is confused about the
> resulting package?
Yes, that would be straightforward and a good idea. It should go into
the Description.
Ian.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tools: Improve make deb
2012-04-24 13:46 ` George Dunlap
2012-04-24 13:56 ` George Dunlap
@ 2012-04-24 14:02 ` Dario Faggioli
2012-04-24 14:20 ` Ian Campbell
2 siblings, 0 replies; 11+ messages in thread
From: Dario Faggioli @ 2012-04-24 14:02 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, Ian Campbell, fantonifabio@tiscali.it
[-- Attachment #1.1: Type: text/plain, Size: 1806 bytes --]
On Tue, 2012-04-24 at 14:46 +0100, George Dunlap wrote:
> On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > I'm just concerned that with these patches you may be trying to turn
> > this simple convenience functionality into something which you think is
> > suitable for end user consumption, which is something we need to think
> > carefully about since there is a maintenance (and expectation) burden
> > imposed by doing that.
>
> I think in an ideal world, "make deb" (or "make rpm") would be used by
> exactly the same people who at the moment do "make install" -- that
> is, fairly technical end-users who have the knowledge to muck about
> with their system; they need to take the responsibility to not shoot
> themselves in the foot (or to bandage it up properly if they do).
>
I see and share Ian's feelings, but I agree with George. :-P
For what it counts, I happen to use kernel-package (make-kpkg) on Debian
systems to build my kernel because it's nice and easy tool to have
package(s) for my very own system.
Trying putting it the other way around, let's say I'd be sad if
make-kpkg weren't there, although I _never_ever_ wanted to distribute to
any kind of users the packages I produced with it.
Does this look close enough to this situation here? (If no, sorry for
the interference :-( ).
> I think it's fairly likely that this will be the case, as long as we set
> the expectations properly in the documentation and so on.
>
Agreed again.
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tools: Improve make deb
2012-04-24 13:46 ` George Dunlap
2012-04-24 13:56 ` George Dunlap
2012-04-24 14:02 ` Dario Faggioli
@ 2012-04-24 14:20 ` Ian Campbell
2012-04-24 16:00 ` Ian Jackson
2 siblings, 1 reply; 11+ messages in thread
From: Ian Campbell @ 2012-04-24 14:20 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, fantonifabio@tiscali.it
On Tue, 2012-04-24 at 14:46 +0100, George Dunlap wrote:
> On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> - Add conffiles to manage main config files on package update
> >> - Add/remove of main services (xencommons, xendomains)
> >
> > I don't have any particular objection to doing this but I think we need
> > to be clear about what the purpose of Xen's "deb" target is.
> >
> > It is intended as a convenience to developers (and perhaps some subset
> > of users), to allow them to do a reasonably clean "uninstall" of Xen
> > installed from source. It is not really intended to provide anything
> > more than that.
> >
> > In particular the packages may not be fully policy compliant and we do
> > not plan to support things such as upgrades and the like. It also may
> > well be the case the installing the .deb is not sufficient to get a
> > working Xen system (i.e. you may still need to do much of the manual
> > configuration which is needed if you are building from source). If users
> > want a good, well supported package, well integrated, policy compliant
> > package for their distro then they should get it from the experts --
> > i.e. from the distro.
> >
> > I'm just concerned that with these patches you may be trying to turn
> > this simple convenience functionality into something which you think is
> > suitable for end user consumption, which is something we need to think
> > carefully about since there is a maintenance (and expectation) burden
> > imposed by doing that.
>
> I think in an ideal world, "make deb" (or "make rpm") would be used by
> exactly the same people who at the moment do "make install" -- that
> is, fairly technical end-users who have the knowledge to muck about
> with their system; they need to take the responsibility to not shoot
> themselves in the foot (or to bandage it up properly if they do). I
> think it's fairly likely that this will be the case, as long as we set
> the expectations properly in the documentation and so on.
That seems reasonable, but much of the functionality being added here
isn't done by "make install", is it?
I'm not actually sure about the update-rc.d but the conf file handling
is clearly not part of "make install"
Ian.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] tools: Improve make deb
2012-04-24 14:20 ` Ian Campbell
@ 2012-04-24 16:00 ` Ian Jackson
0 siblings, 0 replies; 11+ messages in thread
From: Ian Jackson @ 2012-04-24 16:00 UTC (permalink / raw)
To: Ian Campbell; +Cc: George Dunlap, xen-devel, fantonifabio@tiscali.it
Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools: Improve make deb"):
> On Tue, 2012-04-24 at 14:46 +0100, George Dunlap wrote:
...
> > I think in an ideal world, "make deb" (or "make rpm") would be used by
> > exactly the same people who at the moment do "make install" -- that
> > is, fairly technical end-users who have the knowledge to muck about
> > with their system; they need to take the responsibility to not shoot
> > themselves in the foot (or to bandage it up properly if they do). I
> > think it's fairly likely that this will be the case, as long as we set
> > the expectations properly in the documentation and so on.
>
> That seems reasonable, but much of the functionality being added here
> isn't done by "make install", is it?
>
> I'm not actually sure about the update-rc.d but the conf file handling
> is clearly not part of "make install"
Arguably this is a bug in "make install". The "make install" of many
other upstream projects completely fails to overwrite any existing
config files.
So I'm convinced that enabling dpkg's conffile handling for the config
files is the right thing to do.
However, the way this is done in Fabio's patch ...
> +cat >deb/DEBIAN/conffiles <<EOF
> +/etc/xen/xl.conf
> +/etc/xen/xend-config.sxp
> +/etc/default/xendomains
> +/etc/default/xencommons
> +EOF
... is not good. We should mark as a conffile exactly every (plain)
file installed in /etc. This should be done with a simple "find"
rune.
Having considered the ramifications, I'm also convinced that it is
correct for the package name to /not/ contain the version number. The
key question from a dpkg semantics point of view is this: would it
ever make sense to coinstall two different versions ? If it would
then they must have different names. If not then they should not.
Now the packages made by "make deb" claim, entirely for themselves,
various paths. Attempting to coinstall two of them is going to go
very badly: firstly a dpkg file conflict, and then if you override
that, a mess where you have mostly overwritten the old package but
parts of it remain.
So I think if you say "dpkg -i thing_i_just_built.deb" it should
replace the thing you installed previously with the new one. The old
one is definitely not going to work any more anyway and any pieces
of it that remain are just luck.
Thanks,
Ian.
^ permalink raw reply [flat|nested] 11+ messages in thread