Access files of a debian package from postinst script
Is it possible, to access the files of a Debian-package from its postinst script?
usually, I would use something like dpkg -c path/to/deb
, but calling apt/dpkg inside a postinst script isn't possible, right?
Currently, I install the package using dpkg -i path/to/deb
, later the package shall be offered by a repository.
What I am trying to achieve:
dpkg -i myPackage_1.0-0_all.deb
unpacks files (especially *.specialTag)
postinst runs a script, which works with all the *.specialTag files on the system (using find / -name *.specialTag
).
That works fine if there are no old *.specialTag files on the system, because:
If I remove a *.specialTag file from myPackage_1.0-0_all.deb
, create a new version myPackage_1.0-1_all.deb
and install it, then the *.specialTag file is still on the system.
My postinst-script will find it and work with it.
So what I have in mind is not to loop through all files on the system, but only through those I bring with me in myPackage_1.0-1_all.deb
But then I need to call dpkg/apt inside the postinst-script
Thanks.
apt dpkg
add a comment |
Is it possible, to access the files of a Debian-package from its postinst script?
usually, I would use something like dpkg -c path/to/deb
, but calling apt/dpkg inside a postinst script isn't possible, right?
Currently, I install the package using dpkg -i path/to/deb
, later the package shall be offered by a repository.
What I am trying to achieve:
dpkg -i myPackage_1.0-0_all.deb
unpacks files (especially *.specialTag)
postinst runs a script, which works with all the *.specialTag files on the system (using find / -name *.specialTag
).
That works fine if there are no old *.specialTag files on the system, because:
If I remove a *.specialTag file from myPackage_1.0-0_all.deb
, create a new version myPackage_1.0-1_all.deb
and install it, then the *.specialTag file is still on the system.
My postinst-script will find it and work with it.
So what I have in mind is not to loop through all files on the system, but only through those I bring with me in myPackage_1.0-1_all.deb
But then I need to call dpkg/apt inside the postinst-script
Thanks.
apt dpkg
add a comment |
Is it possible, to access the files of a Debian-package from its postinst script?
usually, I would use something like dpkg -c path/to/deb
, but calling apt/dpkg inside a postinst script isn't possible, right?
Currently, I install the package using dpkg -i path/to/deb
, later the package shall be offered by a repository.
What I am trying to achieve:
dpkg -i myPackage_1.0-0_all.deb
unpacks files (especially *.specialTag)
postinst runs a script, which works with all the *.specialTag files on the system (using find / -name *.specialTag
).
That works fine if there are no old *.specialTag files on the system, because:
If I remove a *.specialTag file from myPackage_1.0-0_all.deb
, create a new version myPackage_1.0-1_all.deb
and install it, then the *.specialTag file is still on the system.
My postinst-script will find it and work with it.
So what I have in mind is not to loop through all files on the system, but only through those I bring with me in myPackage_1.0-1_all.deb
But then I need to call dpkg/apt inside the postinst-script
Thanks.
apt dpkg
Is it possible, to access the files of a Debian-package from its postinst script?
usually, I would use something like dpkg -c path/to/deb
, but calling apt/dpkg inside a postinst script isn't possible, right?
Currently, I install the package using dpkg -i path/to/deb
, later the package shall be offered by a repository.
What I am trying to achieve:
dpkg -i myPackage_1.0-0_all.deb
unpacks files (especially *.specialTag)
postinst runs a script, which works with all the *.specialTag files on the system (using find / -name *.specialTag
).
That works fine if there are no old *.specialTag files on the system, because:
If I remove a *.specialTag file from myPackage_1.0-0_all.deb
, create a new version myPackage_1.0-1_all.deb
and install it, then the *.specialTag file is still on the system.
My postinst-script will find it and work with it.
So what I have in mind is not to loop through all files on the system, but only through those I bring with me in myPackage_1.0-1_all.deb
But then I need to call dpkg/apt inside the postinst-script
Thanks.
apt dpkg
apt dpkg
edited Nov 2 at 4:47
Yufenyuy Veyeh Dider
1,5454924
1,5454924
asked Oct 17 '16 at 10:50
dasBaschdi
114
114
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
To get the list of files installed by a package you can use dpkg -L YOUR-PACKAGE-NAME
, and this works as you'd expect during postinst
. (So if your package is named example
the command is dpkg -L example
.)
dpkg -L
seems to work even when the /var/lib/dpkg/lock
lockfile is locked, and in any case the lock is not held during postinst
.
You can also use the file /var/lib/dpkg/info/YOUR-PACKAGE-NAME.list
, which dpkg
creates during the install of the package before running its postinst
. (So if your package is named example
the file is /var/lib/dpkg/info/example.list
.)
Both of the above give a list of all files (and all parent directories up to the root, which you may need to filter out depending on what you're doing) that are contained within the package.
1
+1 And the package name is available as$DPKG_MAINTSCRIPT_PACKAGE
during the script execution if you don't want to hard-code it.
– Gil Hamilton
Dec 14 at 19:07
Are you sure aboutdpkg -L
? AFAIK querying the file list like that doesn't need locking the database, and a quick test seems to work fine.
– muru
Dec 15 at 4:55
@muru I remember when I randpkg -L
withstrace
(tracking forked child processes too) and searched the output I saw that it did indeed open the/var/lib/dpkg/lock
file and then calledflock
on the resultant file descriptor.
– mtraceur
Dec 18 at 18:06
@mtraceur I see. Perhaps you can test runningdpkg -L
in a postinst? Maybe dpkg simply tries to lock, but doesn't fail if it couldn't for query commands.
– muru
Dec 18 at 18:46
1
@muru You're right, I just tested (but on an old system with an olddpkg
: 1.14.25) anddpkg -L
inside thepostinst
worked fine. I suppose that means it's safe, then.
– mtraceur
Dec 18 at 22:20
|
show 2 more comments
As far as I read this schematics, the files should be completely unpacked on postinst. So if you got a file usr/share/foo/script.sh
in the package, you should be able to access this script at /usr/share/foo/script.sh
:
I am aware of that, I can access them from the filesystem, yes, but I want to run a script only over some files (following a naming-pattern), that are brought to the system with my package. The problem is to defer between the files that are already on the system and those I brought with my package. A solution/workaround would be to delete any file following the naming pattern first. Then I could be sure, that I run my script on the right files. But still - I think the most elegant way would be to get a file-list from the debian-package directly.
– dasBaschdi
Oct 17 '16 at 14:25
Perhaps you should tell us, what your goal is with the script.
– Phillip -Zyan K Lee- Stockmann
Oct 17 '16 at 15:30
Okay, I thought that would lead too far from the actual problem (access only the files I brought with a package)
– dasBaschdi
Oct 18 '16 at 8:41
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f838270%2faccess-files-of-a-debian-package-from-postinst-script%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
To get the list of files installed by a package you can use dpkg -L YOUR-PACKAGE-NAME
, and this works as you'd expect during postinst
. (So if your package is named example
the command is dpkg -L example
.)
dpkg -L
seems to work even when the /var/lib/dpkg/lock
lockfile is locked, and in any case the lock is not held during postinst
.
You can also use the file /var/lib/dpkg/info/YOUR-PACKAGE-NAME.list
, which dpkg
creates during the install of the package before running its postinst
. (So if your package is named example
the file is /var/lib/dpkg/info/example.list
.)
Both of the above give a list of all files (and all parent directories up to the root, which you may need to filter out depending on what you're doing) that are contained within the package.
1
+1 And the package name is available as$DPKG_MAINTSCRIPT_PACKAGE
during the script execution if you don't want to hard-code it.
– Gil Hamilton
Dec 14 at 19:07
Are you sure aboutdpkg -L
? AFAIK querying the file list like that doesn't need locking the database, and a quick test seems to work fine.
– muru
Dec 15 at 4:55
@muru I remember when I randpkg -L
withstrace
(tracking forked child processes too) and searched the output I saw that it did indeed open the/var/lib/dpkg/lock
file and then calledflock
on the resultant file descriptor.
– mtraceur
Dec 18 at 18:06
@mtraceur I see. Perhaps you can test runningdpkg -L
in a postinst? Maybe dpkg simply tries to lock, but doesn't fail if it couldn't for query commands.
– muru
Dec 18 at 18:46
1
@muru You're right, I just tested (but on an old system with an olddpkg
: 1.14.25) anddpkg -L
inside thepostinst
worked fine. I suppose that means it's safe, then.
– mtraceur
Dec 18 at 22:20
|
show 2 more comments
To get the list of files installed by a package you can use dpkg -L YOUR-PACKAGE-NAME
, and this works as you'd expect during postinst
. (So if your package is named example
the command is dpkg -L example
.)
dpkg -L
seems to work even when the /var/lib/dpkg/lock
lockfile is locked, and in any case the lock is not held during postinst
.
You can also use the file /var/lib/dpkg/info/YOUR-PACKAGE-NAME.list
, which dpkg
creates during the install of the package before running its postinst
. (So if your package is named example
the file is /var/lib/dpkg/info/example.list
.)
Both of the above give a list of all files (and all parent directories up to the root, which you may need to filter out depending on what you're doing) that are contained within the package.
1
+1 And the package name is available as$DPKG_MAINTSCRIPT_PACKAGE
during the script execution if you don't want to hard-code it.
– Gil Hamilton
Dec 14 at 19:07
Are you sure aboutdpkg -L
? AFAIK querying the file list like that doesn't need locking the database, and a quick test seems to work fine.
– muru
Dec 15 at 4:55
@muru I remember when I randpkg -L
withstrace
(tracking forked child processes too) and searched the output I saw that it did indeed open the/var/lib/dpkg/lock
file and then calledflock
on the resultant file descriptor.
– mtraceur
Dec 18 at 18:06
@mtraceur I see. Perhaps you can test runningdpkg -L
in a postinst? Maybe dpkg simply tries to lock, but doesn't fail if it couldn't for query commands.
– muru
Dec 18 at 18:46
1
@muru You're right, I just tested (but on an old system with an olddpkg
: 1.14.25) anddpkg -L
inside thepostinst
worked fine. I suppose that means it's safe, then.
– mtraceur
Dec 18 at 22:20
|
show 2 more comments
To get the list of files installed by a package you can use dpkg -L YOUR-PACKAGE-NAME
, and this works as you'd expect during postinst
. (So if your package is named example
the command is dpkg -L example
.)
dpkg -L
seems to work even when the /var/lib/dpkg/lock
lockfile is locked, and in any case the lock is not held during postinst
.
You can also use the file /var/lib/dpkg/info/YOUR-PACKAGE-NAME.list
, which dpkg
creates during the install of the package before running its postinst
. (So if your package is named example
the file is /var/lib/dpkg/info/example.list
.)
Both of the above give a list of all files (and all parent directories up to the root, which you may need to filter out depending on what you're doing) that are contained within the package.
To get the list of files installed by a package you can use dpkg -L YOUR-PACKAGE-NAME
, and this works as you'd expect during postinst
. (So if your package is named example
the command is dpkg -L example
.)
dpkg -L
seems to work even when the /var/lib/dpkg/lock
lockfile is locked, and in any case the lock is not held during postinst
.
You can also use the file /var/lib/dpkg/info/YOUR-PACKAGE-NAME.list
, which dpkg
creates during the install of the package before running its postinst
. (So if your package is named example
the file is /var/lib/dpkg/info/example.list
.)
Both of the above give a list of all files (and all parent directories up to the root, which you may need to filter out depending on what you're doing) that are contained within the package.
edited Dec 18 at 22:51
answered Nov 1 at 17:55
mtraceur
1416
1416
1
+1 And the package name is available as$DPKG_MAINTSCRIPT_PACKAGE
during the script execution if you don't want to hard-code it.
– Gil Hamilton
Dec 14 at 19:07
Are you sure aboutdpkg -L
? AFAIK querying the file list like that doesn't need locking the database, and a quick test seems to work fine.
– muru
Dec 15 at 4:55
@muru I remember when I randpkg -L
withstrace
(tracking forked child processes too) and searched the output I saw that it did indeed open the/var/lib/dpkg/lock
file and then calledflock
on the resultant file descriptor.
– mtraceur
Dec 18 at 18:06
@mtraceur I see. Perhaps you can test runningdpkg -L
in a postinst? Maybe dpkg simply tries to lock, but doesn't fail if it couldn't for query commands.
– muru
Dec 18 at 18:46
1
@muru You're right, I just tested (but on an old system with an olddpkg
: 1.14.25) anddpkg -L
inside thepostinst
worked fine. I suppose that means it's safe, then.
– mtraceur
Dec 18 at 22:20
|
show 2 more comments
1
+1 And the package name is available as$DPKG_MAINTSCRIPT_PACKAGE
during the script execution if you don't want to hard-code it.
– Gil Hamilton
Dec 14 at 19:07
Are you sure aboutdpkg -L
? AFAIK querying the file list like that doesn't need locking the database, and a quick test seems to work fine.
– muru
Dec 15 at 4:55
@muru I remember when I randpkg -L
withstrace
(tracking forked child processes too) and searched the output I saw that it did indeed open the/var/lib/dpkg/lock
file and then calledflock
on the resultant file descriptor.
– mtraceur
Dec 18 at 18:06
@mtraceur I see. Perhaps you can test runningdpkg -L
in a postinst? Maybe dpkg simply tries to lock, but doesn't fail if it couldn't for query commands.
– muru
Dec 18 at 18:46
1
@muru You're right, I just tested (but on an old system with an olddpkg
: 1.14.25) anddpkg -L
inside thepostinst
worked fine. I suppose that means it's safe, then.
– mtraceur
Dec 18 at 22:20
1
1
+1 And the package name is available as
$DPKG_MAINTSCRIPT_PACKAGE
during the script execution if you don't want to hard-code it.– Gil Hamilton
Dec 14 at 19:07
+1 And the package name is available as
$DPKG_MAINTSCRIPT_PACKAGE
during the script execution if you don't want to hard-code it.– Gil Hamilton
Dec 14 at 19:07
Are you sure about
dpkg -L
? AFAIK querying the file list like that doesn't need locking the database, and a quick test seems to work fine.– muru
Dec 15 at 4:55
Are you sure about
dpkg -L
? AFAIK querying the file list like that doesn't need locking the database, and a quick test seems to work fine.– muru
Dec 15 at 4:55
@muru I remember when I ran
dpkg -L
with strace
(tracking forked child processes too) and searched the output I saw that it did indeed open the /var/lib/dpkg/lock
file and then called flock
on the resultant file descriptor.– mtraceur
Dec 18 at 18:06
@muru I remember when I ran
dpkg -L
with strace
(tracking forked child processes too) and searched the output I saw that it did indeed open the /var/lib/dpkg/lock
file and then called flock
on the resultant file descriptor.– mtraceur
Dec 18 at 18:06
@mtraceur I see. Perhaps you can test running
dpkg -L
in a postinst? Maybe dpkg simply tries to lock, but doesn't fail if it couldn't for query commands.– muru
Dec 18 at 18:46
@mtraceur I see. Perhaps you can test running
dpkg -L
in a postinst? Maybe dpkg simply tries to lock, but doesn't fail if it couldn't for query commands.– muru
Dec 18 at 18:46
1
1
@muru You're right, I just tested (but on an old system with an old
dpkg
: 1.14.25) and dpkg -L
inside the postinst
worked fine. I suppose that means it's safe, then.– mtraceur
Dec 18 at 22:20
@muru You're right, I just tested (but on an old system with an old
dpkg
: 1.14.25) and dpkg -L
inside the postinst
worked fine. I suppose that means it's safe, then.– mtraceur
Dec 18 at 22:20
|
show 2 more comments
As far as I read this schematics, the files should be completely unpacked on postinst. So if you got a file usr/share/foo/script.sh
in the package, you should be able to access this script at /usr/share/foo/script.sh
:
I am aware of that, I can access them from the filesystem, yes, but I want to run a script only over some files (following a naming-pattern), that are brought to the system with my package. The problem is to defer between the files that are already on the system and those I brought with my package. A solution/workaround would be to delete any file following the naming pattern first. Then I could be sure, that I run my script on the right files. But still - I think the most elegant way would be to get a file-list from the debian-package directly.
– dasBaschdi
Oct 17 '16 at 14:25
Perhaps you should tell us, what your goal is with the script.
– Phillip -Zyan K Lee- Stockmann
Oct 17 '16 at 15:30
Okay, I thought that would lead too far from the actual problem (access only the files I brought with a package)
– dasBaschdi
Oct 18 '16 at 8:41
add a comment |
As far as I read this schematics, the files should be completely unpacked on postinst. So if you got a file usr/share/foo/script.sh
in the package, you should be able to access this script at /usr/share/foo/script.sh
:
I am aware of that, I can access them from the filesystem, yes, but I want to run a script only over some files (following a naming-pattern), that are brought to the system with my package. The problem is to defer between the files that are already on the system and those I brought with my package. A solution/workaround would be to delete any file following the naming pattern first. Then I could be sure, that I run my script on the right files. But still - I think the most elegant way would be to get a file-list from the debian-package directly.
– dasBaschdi
Oct 17 '16 at 14:25
Perhaps you should tell us, what your goal is with the script.
– Phillip -Zyan K Lee- Stockmann
Oct 17 '16 at 15:30
Okay, I thought that would lead too far from the actual problem (access only the files I brought with a package)
– dasBaschdi
Oct 18 '16 at 8:41
add a comment |
As far as I read this schematics, the files should be completely unpacked on postinst. So if you got a file usr/share/foo/script.sh
in the package, you should be able to access this script at /usr/share/foo/script.sh
:
As far as I read this schematics, the files should be completely unpacked on postinst. So if you got a file usr/share/foo/script.sh
in the package, you should be able to access this script at /usr/share/foo/script.sh
:
answered Oct 17 '16 at 11:08
Phillip -Zyan K Lee- Stockmann
1,951620
1,951620
I am aware of that, I can access them from the filesystem, yes, but I want to run a script only over some files (following a naming-pattern), that are brought to the system with my package. The problem is to defer between the files that are already on the system and those I brought with my package. A solution/workaround would be to delete any file following the naming pattern first. Then I could be sure, that I run my script on the right files. But still - I think the most elegant way would be to get a file-list from the debian-package directly.
– dasBaschdi
Oct 17 '16 at 14:25
Perhaps you should tell us, what your goal is with the script.
– Phillip -Zyan K Lee- Stockmann
Oct 17 '16 at 15:30
Okay, I thought that would lead too far from the actual problem (access only the files I brought with a package)
– dasBaschdi
Oct 18 '16 at 8:41
add a comment |
I am aware of that, I can access them from the filesystem, yes, but I want to run a script only over some files (following a naming-pattern), that are brought to the system with my package. The problem is to defer between the files that are already on the system and those I brought with my package. A solution/workaround would be to delete any file following the naming pattern first. Then I could be sure, that I run my script on the right files. But still - I think the most elegant way would be to get a file-list from the debian-package directly.
– dasBaschdi
Oct 17 '16 at 14:25
Perhaps you should tell us, what your goal is with the script.
– Phillip -Zyan K Lee- Stockmann
Oct 17 '16 at 15:30
Okay, I thought that would lead too far from the actual problem (access only the files I brought with a package)
– dasBaschdi
Oct 18 '16 at 8:41
I am aware of that, I can access them from the filesystem, yes, but I want to run a script only over some files (following a naming-pattern), that are brought to the system with my package. The problem is to defer between the files that are already on the system and those I brought with my package. A solution/workaround would be to delete any file following the naming pattern first. Then I could be sure, that I run my script on the right files. But still - I think the most elegant way would be to get a file-list from the debian-package directly.
– dasBaschdi
Oct 17 '16 at 14:25
I am aware of that, I can access them from the filesystem, yes, but I want to run a script only over some files (following a naming-pattern), that are brought to the system with my package. The problem is to defer between the files that are already on the system and those I brought with my package. A solution/workaround would be to delete any file following the naming pattern first. Then I could be sure, that I run my script on the right files. But still - I think the most elegant way would be to get a file-list from the debian-package directly.
– dasBaschdi
Oct 17 '16 at 14:25
Perhaps you should tell us, what your goal is with the script.
– Phillip -Zyan K Lee- Stockmann
Oct 17 '16 at 15:30
Perhaps you should tell us, what your goal is with the script.
– Phillip -Zyan K Lee- Stockmann
Oct 17 '16 at 15:30
Okay, I thought that would lead too far from the actual problem (access only the files I brought with a package)
– dasBaschdi
Oct 18 '16 at 8:41
Okay, I thought that would lead too far from the actual problem (access only the files I brought with a package)
– dasBaschdi
Oct 18 '16 at 8:41
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f838270%2faccess-files-of-a-debian-package-from-postinst-script%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown