Steve Langasek:
> Since this is the Debian changelog rather than an upstream changelog, the
> majority of changes noted are specific to the shared debian directory, of
> which there is precisely one for any set of binary packages that are built
> from a single source package.
Well, first of all,
I may be wrong, but as far as I understood, dh_fixperms is responsible
for changing the owner of the files :
$man dh_fixperms
[...]It makes all files be owned by
root, and it removes group and other write permission from
all files. [...]
Nicolas.
> >because it forces everything to look like it's owned by root. Use
> >sudo.
>
> That's not true:
You're right, as long as you haven't exited fakeroot and started it up
again in the meantime; I didn't realize that.
--
thanks,
[EMAIL PROTECTED] wrote:
>For situations where you need a file in debian/tmp to be owned by
>somebody other than root, don't use fakeroot to build the package,
>because it forces everything to look like it's owned by root. Use
>sudo.
That's not true:
[EMAIL PROTECTED] ~]$ fakeroot
[EMAIL PRO
[EMAIL PROTECTED] wrote:
> The short answer is to have them owned by the correct person in the
> debian/tmp (or, which newer debhelper versions, debian/)
> directory.
Right.
> For situations where you need a file in debian/tmp to be owned by
> somebody other than root, don't use fakeroot to bu
* Hugo van der Merwe <[EMAIL PROTECTED]> [20010718 12:56]:
> My package failed to build on hppa. I have updated the config.guess
> and config.sub, which did fix some problems, but I cannot be 100%
> sure whether it works now, as I cannot complete the compilation:
> build-dependencies are not met. I
Greetings,
I'm trying to make petsc Build-Depends: on atlas for most arches, but
lapack where there is no atlas. Actually, to make things simpler inside
the package, I link against lapack on PPC, m68k and sparc, so they can
share configuration information, since they are all 32-bit big-endian
> >because it forces everything to look like it's owned by root. Use
> >sudo.
>
> That's not true:
You're right, as long as you haven't exited fakeroot and started it up
again in the meantime; I didn't realize that.
--
thanks,
Steve McWilliams <[EMAIL PROTECTED]> wrote:
>I have read through the debian packaging documentation and am playing
>around with it currently, however I have not yet figured out how to
>control the ownership of files installed from a binary debian package.
>I realize that normally installed package
The short answer is to have them owned by the correct person in the
debian/tmp (or, which newer debhelper versions, debian/)
directory.
For situations where you need a file in debian/tmp to be owned by
somebody other than root, don't use fakeroot to build the package,
because it forces everything
[EMAIL PROTECTED] wrote:
>For situations where you need a file in debian/tmp to be owned by
>somebody other than root, don't use fakeroot to build the package,
>because it forces everything to look like it's owned by root. Use
>sudo.
That's not true:
[cjw44@riva ~]$ fakeroot
[root@riva ~]#
[EMAIL PROTECTED] wrote:
> The short answer is to have them owned by the correct person in the
> debian/tmp (or, which newer debhelper versions, debian/)
> directory.
Right.
> For situations where you need a file in debian/tmp to be owned by
> somebody other than root, don't use fakeroot to b
Greetings,
I'm trying to make petsc Build-Depends: on atlas for most arches, but
lapack where there is no atlas. Actually, to make things simpler inside
the package, I link against lapack on PPC, m68k and sparc, so they can
share configuration information, since they are all 32-bit big-endian
Hello,
I have read through the debian packaging documentation and am playing
around with it currently, however I have not yet figured out how to
control the ownership of files installed from a binary debian package.
I realize that normally installed package files should be owned by root,
however I
Steve McWilliams <[EMAIL PROTECTED]> wrote:
>I have read through the debian packaging documentation and am playing
>around with it currently, however I have not yet figured out how to
>control the ownership of files installed from a binary debian package.
>I realize that normally installed package
The short answer is to have them owned by the correct person in the
debian/tmp (or, which newer debhelper versions, debian/)
directory.
For situations where you need a file in debian/tmp to be owned by
somebody other than root, don't use fakeroot to build the package,
because it forces everything
Hello,
I have read through the debian packaging documentation and am playing
around with it currently, however I have not yet figured out how to
control the ownership of files installed from a binary debian package.
I realize that normally installed package files should be owned by root,
however
On Thu, 19 Jul 2001, peter karlsson wrote:
> > You can't do that, changelogs have to be shared.
> Why? The changelog lists what was changed between the versions, and that
> differens between the two binary packages I created (there was a feature
> only added to the command line version, not the G
Thanks a lot Joey. You were completely right, dpkg handles the situation
perfectly.
Regards,
Alberto
On Thu, Jul 19, 2001 at 07:59:27AM -0400, Joey Hess wrote:
> Alberto Gonzalez Iniesta wrote:
> > The problem is that /etc/multiCDrc is not a conffile yet, so making it a
> > conffile now won't av
* Hugo van der Merwe <[EMAIL PROTECTED]> [20010718 12:56]:
> My package failed to build on hppa. I have updated the config.guess
> and config.sub, which did fix some problems, but I cannot be 100%
> sure whether it works now, as I cannot complete the compilation:
> build-dependencies are not met.
Alberto Gonzalez Iniesta wrote:
> The problem is that /etc/multiCDrc is not a conffile yet, so making it a
> conffile now won't avoid overwriting it when updating to the new version
> in case it exists now. Or will it?
I think dpkg handles this ok, and compares the md5sum of the existing
file (if
On Jul 19, 1:27pm, peter karlsson wrote:
> Why? The changelog lists what was changed between the versions, and that
> differens between the two binary packages I created (there was a feature
> only added to the command line version, not the GUI version), and I want
> that reflected in the changelo
On Thu, 19 Jul 2001, peter karlsson wrote:
> > You can't do that, changelogs have to be shared.
> Why? The changelog lists what was changed between the versions, and that
> differens between the two binary packages I created (there was a feature
> only added to the command line version, not the
Alberto Gonzalez Iniesta dijo:
> The problem is that /etc/multiCDrc is not a conffile yet, so making it a
> conffile now won't avoid overwriting it when updating to the new version in
> case it exists now. Or will it?
Maybe you should just check in your preinst and prompt the user.
--
Do
Wichert Akkerman:
> You can't do that, changelogs have to be shared.
Why? The changelog lists what was changed between the versions, and that
differens between the two binary packages I created (there was a feature
only added to the command line version, not the GUI version), and I want
that refl
Thanks Pedro,
The problem is that /etc/multiCDrc is not a conffile yet, so making it a
conffile now won't avoid overwriting it when updating to the new version
in case it exists now. Or will it?
I mean, shouldn't it have to be a conffile in the previous version so
updating the package would tak
Previously peter karlsson wrote:
> dpkg-gencontrol: error: source package has two conflicting values - turqstat
> and xturqstat
debian/changelog and debian/control have different for the package name.
> My source package "turqstat" generates two binary packages, "turqstat"
> and "xturqstat". They
On Thu, Jul 19, 2001 at 11:55:48AM +0200, Alberto Gonzalez Iniesta wrote:
> Hi all!
> 2) In case of using it as global config file, and since it's not a
> conffile today, wouldn't it overwrite /etc/multiCDrc in case it was
> created by the local admin?
Hi Alberto,
Check http://www.debian.org/do
Thanks a lot Joey. You were completely right, dpkg handles the situation
perfectly.
Regards,
Alberto
On Thu, Jul 19, 2001 at 07:59:27AM -0400, Joey Hess wrote:
> Alberto Gonzalez Iniesta wrote:
> > The problem is that /etc/multiCDrc is not a conffile yet, so making it a
> > conffile now won't a
Hi all!
I'm in the process of becoming a NM. In the meantime I'm working on a
couple of packages.
There's a bug reported in one of them (see:
http://bugs.debian.org/104476) that asks the sample config file which
comes with the upstream distribution to be used as global config file.
This config f
Alberto Gonzalez Iniesta wrote:
> The problem is that /etc/multiCDrc is not a conffile yet, so making it a
> conffile now won't avoid overwriting it when updating to the new version
> in case it exists now. Or will it?
I think dpkg handles this ok, and compares the md5sum of the existing
file (i
On Jul 19, 1:27pm, peter karlsson wrote:
> Why? The changelog lists what was changed between the versions, and that
> differens between the two binary packages I created (there was a feature
> only added to the command line version, not the GUI version), and I want
> that reflected in the changel
Alberto Gonzalez Iniesta dijo:
> The problem is that /etc/multiCDrc is not a conffile yet, so making it a
> conffile now won't avoid overwriting it when updating to the new version in
> case it exists now. Or will it?
Maybe you should just check in your preinst and prompt the user.
--
D
Wichert Akkerman:
> You can't do that, changelogs have to be shared.
Why? The changelog lists what was changed between the versions, and that
differens between the two binary packages I created (there was a feature
only added to the command line version, not the GUI version), and I want
that ref
Thanks Pedro,
The problem is that /etc/multiCDrc is not a conffile yet, so making it a
conffile now won't avoid overwriting it when updating to the new version
in case it exists now. Or will it?
I mean, shouldn't it have to be a conffile in the previous version so
updating the package would ta
Previously peter karlsson wrote:
> dpkg-gencontrol: error: source package has two conflicting values - turqstat
> and xturqstat
debian/changelog and debian/control have different for the package name.
> My source package "turqstat" generates two binary packages, "turqstat"
> and "xturqstat". The
On Thu, Jul 19, 2001 at 11:55:48AM +0200, Alberto Gonzalez Iniesta wrote:
> Hi all!
> 2) In case of using it as global config file, and since it's not a
> conffile today, wouldn't it overwrite /etc/multiCDrc in case it was
> created by the local admin?
Hi Alberto,
Check http://www.debian.org/d
Hi all!
I'm in the process of becoming a NM. In the meantime I'm working on a
couple of packages.
There's a bug reported in one of them (see:
http://bugs.debian.org/104476) that asks the sample config file which
comes with the upstream distribution to be used as global config file.
This config
38 matches
Mail list logo
