Bonjour,
Je souhaite utiliser le gestionnaire de paquets (paquetages ?) de Debian
pour pouvoir installer des logiciels en local (sous /home/olive/local)
plutôt que de faire simplement un ./configure
--prefix=/home/olive/local && make && make install
Cela pour des raisons d'installation/réinstallation rapide.
Pour cela je souhaite utiliser checkinstall qui devrait me créer un .deb
qui s'installera automatiquement dans /home/olive/local.
Cependant si la création du paquet se passe bien, je ne peux pas
l'installer car les droits d'exécutions de dpkg sont restreint à root
bien que l'installation ne devrait pas écrire ailleurs que
/home/olive/local.
Est-ce que cela pose un problème si je change les droits d'exécutions de
dpkg ?
Ou bien y a-t-il une autre manière plus élégante de procéder pour faire
ce que je veux ?
Merci d'avance pour votre aide,
Bonjour,
Je souhaite utiliser le gestionnaire de paquets (paquetages ?) de Debian
pour pouvoir installer des logiciels en local (sous /home/olive/local)
plutôt que de faire simplement un ./configure
--prefix=/home/olive/local && make && make install
Cela pour des raisons d'installation/réinstallation rapide.
Pour cela je souhaite utiliser checkinstall qui devrait me créer un .deb
qui s'installera automatiquement dans /home/olive/local.
Cependant si la création du paquet se passe bien, je ne peux pas
l'installer car les droits d'exécutions de dpkg sont restreint à root
bien que l'installation ne devrait pas écrire ailleurs que
/home/olive/local.
Est-ce que cela pose un problème si je change les droits d'exécutions de
dpkg ?
Ou bien y a-t-il une autre manière plus élégante de procéder pour faire
ce que je veux ?
Merci d'avance pour votre aide,
Bonjour,
Je souhaite utiliser le gestionnaire de paquets (paquetages ?) de Debian
pour pouvoir installer des logiciels en local (sous /home/olive/local)
plutôt que de faire simplement un ./configure
--prefix=/home/olive/local && make && make install
Cela pour des raisons d'installation/réinstallation rapide.
Pour cela je souhaite utiliser checkinstall qui devrait me créer un .deb
qui s'installera automatiquement dans /home/olive/local.
Cependant si la création du paquet se passe bien, je ne peux pas
l'installer car les droits d'exécutions de dpkg sont restreint à root
bien que l'installation ne devrait pas écrire ailleurs que
/home/olive/local.
Est-ce que cela pose un problème si je change les droits d'exécutions de
dpkg ?
Ou bien y a-t-il une autre manière plus élégante de procéder pour faire
ce que je veux ?
Merci d'avance pour votre aide,
>Je souhaite utiliser le gestionnaire de paquets (paquetages ?) de
>Debian pour pouvoir installer des logiciels en local (sous
>/home/olive/local) plutôt que de faire simplement un ./configure
>--prefix=/home/olive/local && make && make install
>
>Cela pour des raisons d'installation/réinstallation rapide.
>
>Pour cela je souhaite utiliser checkinstall qui devrait me créer un
>.deb qui s'installera automatiquement dans /home/olive/local.
>
>Cependant si la création du paquet se passe bien, je ne peux pas
>l'installer car les droits d'exécutions de dpkg sont restreint à root
>bien que l'installation ne devrait pas écrire ailleurs que
>/home/olive/local.
>
>Est-ce que cela pose un problème si je change les droits d'exécutions
>de dpkg ?
>
>
>
potentiellement oui.
>Ou bien y a-t-il une autre manière plus élégante de procéder pour
>faire ce que je veux ?
>
>
>
sudo : configurer le fichier /etc/sudoers
ex:
Cmnd_Alias UPGRADE=/usr/bin/apt-get update, /usr/bin/apt-get upgrade
root ALL=(ALL) ALL
<user> ALL= NOPASSWD : UPGRADE
puis avec <user> : sudo apt-get update/upgrade
>Je souhaite utiliser le gestionnaire de paquets (paquetages ?) de
>Debian pour pouvoir installer des logiciels en local (sous
>/home/olive/local) plutôt que de faire simplement un ./configure
>--prefix=/home/olive/local && make && make install
>
>Cela pour des raisons d'installation/réinstallation rapide.
>
>Pour cela je souhaite utiliser checkinstall qui devrait me créer un
>.deb qui s'installera automatiquement dans /home/olive/local.
>
>Cependant si la création du paquet se passe bien, je ne peux pas
>l'installer car les droits d'exécutions de dpkg sont restreint à root
>bien que l'installation ne devrait pas écrire ailleurs que
>/home/olive/local.
>
>Est-ce que cela pose un problème si je change les droits d'exécutions
>de dpkg ?
>
>
>
potentiellement oui.
>Ou bien y a-t-il une autre manière plus élégante de procéder pour
>faire ce que je veux ?
>
>
>
sudo : configurer le fichier /etc/sudoers
ex:
Cmnd_Alias UPGRADE=/usr/bin/apt-get update, /usr/bin/apt-get upgrade
root ALL=(ALL) ALL
<user> ALL= NOPASSWD : UPGRADE
puis avec <user> : sudo apt-get update/upgrade
>Je souhaite utiliser le gestionnaire de paquets (paquetages ?) de
>Debian pour pouvoir installer des logiciels en local (sous
>/home/olive/local) plutôt que de faire simplement un ./configure
>--prefix=/home/olive/local && make && make install
>
>Cela pour des raisons d'installation/réinstallation rapide.
>
>Pour cela je souhaite utiliser checkinstall qui devrait me créer un
>.deb qui s'installera automatiquement dans /home/olive/local.
>
>Cependant si la création du paquet se passe bien, je ne peux pas
>l'installer car les droits d'exécutions de dpkg sont restreint à root
>bien que l'installation ne devrait pas écrire ailleurs que
>/home/olive/local.
>
>Est-ce que cela pose un problème si je change les droits d'exécutions
>de dpkg ?
>
>
>
potentiellement oui.
>Ou bien y a-t-il une autre manière plus élégante de procéder pour
>faire ce que je veux ?
>
>
>
sudo : configurer le fichier /etc/sudoers
ex:
Cmnd_Alias UPGRADE=/usr/bin/apt-get update, /usr/bin/apt-get upgrade
root ALL=(ALL) ALL
<user> ALL= NOPASSWD : UPGRADE
puis avec <user> : sudo apt-get update/upgrade
On Wed, 15 Sep 2004 07:33:12 +0200, JusTiCe8 wrote
[...]Est-ce que cela pose un problème si je change les droits d'exécutions
de dpkg ?
potentiellement oui.
Par exemple ?
Ou bien y a-t-il une autre manière plus élégante de procéder pour
faire ce que je veux ?
sudo : configurer le fichier /etc/sudoers
ex:
Cmnd_Alias UPGRADE=/usr/bin/apt-get update, /usr/bin/apt-get upgrade
root ALL=(ALL) ALL
<user> ALL= NOPASSWD : UPGRADE
puis avec <user> : sudo apt-get update/upgrade
Cela m'ennuie un peu avec sudo.
En effet (après coup) je pars du principe que ce sera sur une Debian
installée sur le réseau d'une entreprise et donc je préfère ne pas
déranger l'administrateur pour cela (du coup cela m'interdit aussi
dpkg) s'il y a des risques potentiels...
Je crois que je vais plutôt m'orienter vers GNU stow alors...
Merci pour ton aide !
On Wed, 15 Sep 2004 07:33:12 +0200, JusTiCe8 <justice8@wanadoo.fr> wrote
[...]
Est-ce que cela pose un problème si je change les droits d'exécutions
de dpkg ?
potentiellement oui.
Par exemple ?
Ou bien y a-t-il une autre manière plus élégante de procéder pour
faire ce que je veux ?
sudo : configurer le fichier /etc/sudoers
ex:
Cmnd_Alias UPGRADE=/usr/bin/apt-get update, /usr/bin/apt-get upgrade
root ALL=(ALL) ALL
<user> ALL= NOPASSWD : UPGRADE
puis avec <user> : sudo apt-get update/upgrade
Cela m'ennuie un peu avec sudo.
En effet (après coup) je pars du principe que ce sera sur une Debian
installée sur le réseau d'une entreprise et donc je préfère ne pas
déranger l'administrateur pour cela (du coup cela m'interdit aussi
dpkg) s'il y a des risques potentiels...
Je crois que je vais plutôt m'orienter vers GNU stow alors...
Merci pour ton aide !
On Wed, 15 Sep 2004 07:33:12 +0200, JusTiCe8 wrote
[...]Est-ce que cela pose un problème si je change les droits d'exécutions
de dpkg ?
potentiellement oui.
Par exemple ?
Ou bien y a-t-il une autre manière plus élégante de procéder pour
faire ce que je veux ?
sudo : configurer le fichier /etc/sudoers
ex:
Cmnd_Alias UPGRADE=/usr/bin/apt-get update, /usr/bin/apt-get upgrade
root ALL=(ALL) ALL
<user> ALL= NOPASSWD : UPGRADE
puis avec <user> : sudo apt-get update/upgrade
Cela m'ennuie un peu avec sudo.
En effet (après coup) je pars du principe que ce sera sur une Debian
installée sur le réseau d'une entreprise et donc je préfère ne pas
déranger l'administrateur pour cela (du coup cela m'interdit aussi
dpkg) s'il y a des risques potentiels...
Je crois que je vais plutôt m'orienter vers GNU stow alors...
Merci pour ton aide !
> > > > Est-ce que cela pose un problème si je change les droits
> > > d'exécutions de dpkg ?
> > potentiellement oui.
> Par exemple ?
n'importe qui pourrait lancer dpkg (imagine un dpkg -remove libc6* :)
)
>Cela m'ennuie un peu avec sudo.
>En effet (après coup) je pars du principe que ce sera sur une Debian
>installée sur le réseau d'une entreprise et donc je préfère ne pas
>déranger l'administrateur pour cela (du coup cela m'interdit aussi
>dpkg) s'il y a des risques potentiels...
>
>
Dans ce cas, tu n'as pas d'accès "root", donc même pas de possibilité
d'installer un quelconque package, ou je me trompe ? Dans le cas où la
machine est pour le moment sous ton contrôle absolue, configure sudo
au p'tits ognons et après, rouler jeunesse :).
> > > > Est-ce que cela pose un problème si je change les droits
> > > d'exécutions de dpkg ?
> > potentiellement oui.
> Par exemple ?
n'importe qui pourrait lancer dpkg (imagine un dpkg -remove libc6* :)
)
>Cela m'ennuie un peu avec sudo.
>En effet (après coup) je pars du principe que ce sera sur une Debian
>installée sur le réseau d'une entreprise et donc je préfère ne pas
>déranger l'administrateur pour cela (du coup cela m'interdit aussi
>dpkg) s'il y a des risques potentiels...
>
>
Dans ce cas, tu n'as pas d'accès "root", donc même pas de possibilité
d'installer un quelconque package, ou je me trompe ? Dans le cas où la
machine est pour le moment sous ton contrôle absolue, configure sudo
au p'tits ognons et après, rouler jeunesse :).
> > > > Est-ce que cela pose un problème si je change les droits
> > > d'exécutions de dpkg ?
> > potentiellement oui.
> Par exemple ?
n'importe qui pourrait lancer dpkg (imagine un dpkg -remove libc6* :)
)
>Cela m'ennuie un peu avec sudo.
>En effet (après coup) je pars du principe que ce sera sur une Debian
>installée sur le réseau d'une entreprise et donc je préfère ne pas
>déranger l'administrateur pour cela (du coup cela m'interdit aussi
>dpkg) s'il y a des risques potentiels...
>
>
Dans ce cas, tu n'as pas d'accès "root", donc même pas de possibilité
d'installer un quelconque package, ou je me trompe ? Dans le cas où la
machine est pour le moment sous ton contrôle absolue, configure sudo
au p'tits ognons et après, rouler jeunesse :).
Est-ce que cela pose un problème si je change les droits
d'exécutions de dpkg ?
potentiellement oui.
Par exemple ?
n'importe qui pourrait lancer dpkg (imagine un dpkg -remove libc6* :)
)
Mais libc6 appartient à root, je ne peux pas l'enlever comme ça !
Cela m'ennuie un peu avec sudo.
En effet (après coup) je pars du principe que ce sera sur une Debian
installée sur le réseau d'une entreprise et donc je préfère ne pas
déranger l'administrateur pour cela (du coup cela m'interdit aussi
dpkg) s'il y a des risques potentiels...
Dans ce cas, tu n'as pas d'accès "root", donc même pas de possibilité
d'installer un quelconque package, ou je me trompe ? Dans le cas où la
machine est pour le moment sous ton contrôle absolue, configure sudo
au p'tits ognons et après, rouler jeunesse :).
Oui je n'ai pas d'accès "root" mais je peux toujours installer ce que je
veux sous mon compte en local : c'est l'avantage de Linux !
Par contre je souhaitais mettre un peu d'ordre dans mes "make install"
sauvages et je voulais donc utiliser un système de paquetages (dpkg).
Mais cela n'a pas l'air d'être possible, même si c'est pour installer en
local, c'est dommage...
Si tu as plus d'idées...
Merci quand même !
Est-ce que cela pose un problème si je change les droits
d'exécutions de dpkg ?
potentiellement oui.
Par exemple ?
n'importe qui pourrait lancer dpkg (imagine un dpkg -remove libc6* :)
)
Mais libc6 appartient à root, je ne peux pas l'enlever comme ça !
Cela m'ennuie un peu avec sudo.
En effet (après coup) je pars du principe que ce sera sur une Debian
installée sur le réseau d'une entreprise et donc je préfère ne pas
déranger l'administrateur pour cela (du coup cela m'interdit aussi
dpkg) s'il y a des risques potentiels...
Dans ce cas, tu n'as pas d'accès "root", donc même pas de possibilité
d'installer un quelconque package, ou je me trompe ? Dans le cas où la
machine est pour le moment sous ton contrôle absolue, configure sudo
au p'tits ognons et après, rouler jeunesse :).
Oui je n'ai pas d'accès "root" mais je peux toujours installer ce que je
veux sous mon compte en local : c'est l'avantage de Linux !
Par contre je souhaitais mettre un peu d'ordre dans mes "make install"
sauvages et je voulais donc utiliser un système de paquetages (dpkg).
Mais cela n'a pas l'air d'être possible, même si c'est pour installer en
local, c'est dommage...
Si tu as plus d'idées...
Merci quand même !
Est-ce que cela pose un problème si je change les droits
d'exécutions de dpkg ?
potentiellement oui.
Par exemple ?
n'importe qui pourrait lancer dpkg (imagine un dpkg -remove libc6* :)
)
Mais libc6 appartient à root, je ne peux pas l'enlever comme ça !
Cela m'ennuie un peu avec sudo.
En effet (après coup) je pars du principe que ce sera sur une Debian
installée sur le réseau d'une entreprise et donc je préfère ne pas
déranger l'administrateur pour cela (du coup cela m'interdit aussi
dpkg) s'il y a des risques potentiels...
Dans ce cas, tu n'as pas d'accès "root", donc même pas de possibilité
d'installer un quelconque package, ou je me trompe ? Dans le cas où la
machine est pour le moment sous ton contrôle absolue, configure sudo
au p'tits ognons et après, rouler jeunesse :).
Oui je n'ai pas d'accès "root" mais je peux toujours installer ce que je
veux sous mon compte en local : c'est l'avantage de Linux !
Par contre je souhaitais mettre un peu d'ordre dans mes "make install"
sauvages et je voulais donc utiliser un système de paquetages (dpkg).
Mais cela n'a pas l'air d'être possible, même si c'est pour installer en
local, c'est dommage...
Si tu as plus d'idées...
Merci quand même !
A la base, la gestion des paquets est justement pour le système entier,
donc droits root nécéssaires.
>Mais cela n'a pas l'air d'être possible, même si c'est pour installer en
>local, c'est dommage...
>
>
oui, à moins de changer le répertoire de base, mais j'ai jamais fait et
puis de toutes manières, dpkg et ses "amis" ;) utilisent des fichiers
situés dans /var/lib/dpkg, donc droit root encore nécéssaire ici (ou
délégation via sudo/groupe/...)
A la base, la gestion des paquets est justement pour le système entier,
donc droits root nécéssaires.
>Mais cela n'a pas l'air d'être possible, même si c'est pour installer en
>local, c'est dommage...
>
>
oui, à moins de changer le répertoire de base, mais j'ai jamais fait et
puis de toutes manières, dpkg et ses "amis" ;) utilisent des fichiers
situés dans /var/lib/dpkg, donc droit root encore nécéssaire ici (ou
délégation via sudo/groupe/...)
A la base, la gestion des paquets est justement pour le système entier,
donc droits root nécéssaires.
>Mais cela n'a pas l'air d'être possible, même si c'est pour installer en
>local, c'est dommage...
>
>
oui, à moins de changer le répertoire de base, mais j'ai jamais fait et
puis de toutes manières, dpkg et ses "amis" ;) utilisent des fichiers
situés dans /var/lib/dpkg, donc droit root encore nécéssaire ici (ou
délégation via sudo/groupe/...)
>>>>>Est-ce que cela pose un problème si je change les droits
>>>>>d'exécutions de dpkg ?
>>>>>
>>>>>
>>>>potentiellement oui.
>>>>
>>>>
>>>Par exemple ?
>>>
>>>
>>n'importe qui pourrait lancer dpkg (imagine un dpkg -remove libc6*
>:)>)
>>
>>
>
>Mais libc6 appartient à root, je ne peux pas l'enlever comme ça !
>
>
>
>
Faux !
Aucun paquet n'"appartient" au sens strict su terme à un utilisateur
et un utilisateur auquel "root" délègue ses droits de gestion de
paquets peut ajouter supprimer des paquets selon son bon vouloir.
>>>Cela m'ennuie un peu avec sudo.
>>>En effet (après coup) je pars du principe que ce sera sur une
>Debian>>installée sur le réseau d'une entreprise et donc je préfère
>ne pas>>déranger l'administrateur pour cela (du coup cela m'interdit
>aussi>>dpkg) s'il y a des risques potentiels...
>>>
>>>
>>>
>>>
>>Dans ce cas, tu n'as pas d'accès "root", donc même pas de
>possibilité >d'installer un quelconque package, ou je me trompe ?
>Dans le cas où la>machine est pour le moment sous ton contrôle
>absolue, configure sudo>au p'tits ognons et après, rouler jeunesse
>:).>
>>
>
>Oui je n'ai pas d'accès "root" mais je peux toujours installer ce que
>je veux sous mon compte en local : c'est l'avantage de Linux !
>
>
Certe, mais ça ne permettra jamais les upgrades ni les install
"system-wide".
>Par contre je souhaitais mettre un peu d'ordre dans mes "make
>install" sauvages et je voulais donc utiliser un système de
>paquetages (dpkg).
>
>
A la base, la gestion des paquets est justement pour le système
entier, donc droits root nécéssaires.
A moins d'utiliser stow comme tu l'as suggérer ou refaire desp aquets
dont le rep de base est "/usr/local" par exemple au lieu de "/"
>Mais cela n'a pas l'air d'être possible, même si c'est pour installer
>en local, c'est dommage...
>
>
oui, à moins de changer le répertoire de base, mais j'ai jamais fait
et puis de toutes manières, dpkg et ses "amis" ;) utilisent des
fichiers situés dans /var/lib/dpkg, donc droit root encore nécéssaire
ici (ou délégation via sudo/groupe/...)
>Si tu as plus d'idées...
>
>
Stow correspond le mieux à ton souhait, sinon comme la machine ne
semble pas encore entre les mains d'un "root" tout puissant, ou alors
sudo comme dit précédemment, tu le fait une foit pour toute avant
livraison et après plus besoin d'ennuyer le gentil monsieur pour les
paquets.
>>>>>Est-ce que cela pose un problème si je change les droits
>>>>>d'exécutions de dpkg ?
>>>>>
>>>>>
>>>>potentiellement oui.
>>>>
>>>>
>>>Par exemple ?
>>>
>>>
>>n'importe qui pourrait lancer dpkg (imagine un dpkg -remove libc6*
>:)>)
>>
>>
>
>Mais libc6 appartient à root, je ne peux pas l'enlever comme ça !
>
>
>
>
Faux !
Aucun paquet n'"appartient" au sens strict su terme à un utilisateur
et un utilisateur auquel "root" délègue ses droits de gestion de
paquets peut ajouter supprimer des paquets selon son bon vouloir.
>>>Cela m'ennuie un peu avec sudo.
>>>En effet (après coup) je pars du principe que ce sera sur une
>Debian>>installée sur le réseau d'une entreprise et donc je préfère
>ne pas>>déranger l'administrateur pour cela (du coup cela m'interdit
>aussi>>dpkg) s'il y a des risques potentiels...
>>>
>>>
>>>
>>>
>>Dans ce cas, tu n'as pas d'accès "root", donc même pas de
>possibilité >d'installer un quelconque package, ou je me trompe ?
>Dans le cas où la>machine est pour le moment sous ton contrôle
>absolue, configure sudo>au p'tits ognons et après, rouler jeunesse
>:).>
>>
>
>Oui je n'ai pas d'accès "root" mais je peux toujours installer ce que
>je veux sous mon compte en local : c'est l'avantage de Linux !
>
>
Certe, mais ça ne permettra jamais les upgrades ni les install
"system-wide".
>Par contre je souhaitais mettre un peu d'ordre dans mes "make
>install" sauvages et je voulais donc utiliser un système de
>paquetages (dpkg).
>
>
A la base, la gestion des paquets est justement pour le système
entier, donc droits root nécéssaires.
A moins d'utiliser stow comme tu l'as suggérer ou refaire desp aquets
dont le rep de base est "/usr/local" par exemple au lieu de "/"
>Mais cela n'a pas l'air d'être possible, même si c'est pour installer
>en local, c'est dommage...
>
>
oui, à moins de changer le répertoire de base, mais j'ai jamais fait
et puis de toutes manières, dpkg et ses "amis" ;) utilisent des
fichiers situés dans /var/lib/dpkg, donc droit root encore nécéssaire
ici (ou délégation via sudo/groupe/...)
>Si tu as plus d'idées...
>
>
Stow correspond le mieux à ton souhait, sinon comme la machine ne
semble pas encore entre les mains d'un "root" tout puissant, ou alors
sudo comme dit précédemment, tu le fait une foit pour toute avant
livraison et après plus besoin d'ennuyer le gentil monsieur pour les
paquets.
>>>>>Est-ce que cela pose un problème si je change les droits
>>>>>d'exécutions de dpkg ?
>>>>>
>>>>>
>>>>potentiellement oui.
>>>>
>>>>
>>>Par exemple ?
>>>
>>>
>>n'importe qui pourrait lancer dpkg (imagine un dpkg -remove libc6*
>:)>)
>>
>>
>
>Mais libc6 appartient à root, je ne peux pas l'enlever comme ça !
>
>
>
>
Faux !
Aucun paquet n'"appartient" au sens strict su terme à un utilisateur
et un utilisateur auquel "root" délègue ses droits de gestion de
paquets peut ajouter supprimer des paquets selon son bon vouloir.
>>>Cela m'ennuie un peu avec sudo.
>>>En effet (après coup) je pars du principe que ce sera sur une
>Debian>>installée sur le réseau d'une entreprise et donc je préfère
>ne pas>>déranger l'administrateur pour cela (du coup cela m'interdit
>aussi>>dpkg) s'il y a des risques potentiels...
>>>
>>>
>>>
>>>
>>Dans ce cas, tu n'as pas d'accès "root", donc même pas de
>possibilité >d'installer un quelconque package, ou je me trompe ?
>Dans le cas où la>machine est pour le moment sous ton contrôle
>absolue, configure sudo>au p'tits ognons et après, rouler jeunesse
>:).>
>>
>
>Oui je n'ai pas d'accès "root" mais je peux toujours installer ce que
>je veux sous mon compte en local : c'est l'avantage de Linux !
>
>
Certe, mais ça ne permettra jamais les upgrades ni les install
"system-wide".
>Par contre je souhaitais mettre un peu d'ordre dans mes "make
>install" sauvages et je voulais donc utiliser un système de
>paquetages (dpkg).
>
>
A la base, la gestion des paquets est justement pour le système
entier, donc droits root nécéssaires.
A moins d'utiliser stow comme tu l'as suggérer ou refaire desp aquets
dont le rep de base est "/usr/local" par exemple au lieu de "/"
>Mais cela n'a pas l'air d'être possible, même si c'est pour installer
>en local, c'est dommage...
>
>
oui, à moins de changer le répertoire de base, mais j'ai jamais fait
et puis de toutes manières, dpkg et ses "amis" ;) utilisent des
fichiers situés dans /var/lib/dpkg, donc droit root encore nécéssaire
ici (ou délégation via sudo/groupe/...)
>Si tu as plus d'idées...
>
>
Stow correspond le mieux à ton souhait, sinon comme la machine ne
semble pas encore entre les mains d'un "root" tout puissant, ou alors
sudo comme dit précédemment, tu le fait une foit pour toute avant
livraison et après plus besoin d'ennuyer le gentil monsieur pour les
paquets.
> A la base, la gestion des paquets est justement pour le système
> entier, donc droits root nécéssaires.
C'est bien dommage :-)
Qqch que j'ai commencé à essayer, maic ça ne marche pas
"directement":
fakeroot debootstrap woody /home/toto/local
va installer une arborescence de base dans /home/totolocal,
en particulier un /home/toto/local/var/lib/dpkg, tout ça
appartenant à toto. L'idée serait ensuite de faire
fakeroot dpkg --root /home/toto/local -i foobar.deb
mais dpkg semble insister à vouloir faire un chroot() auquel
il n'a pas droit. En fait, le plus simple serait
peut-être de patcher dpkg pour mieux supporter l'option
--root sans être superutilisateur. Il n'y a a priori aucune
raison pour qu'on ne puisse pas faire ce que tu veux...
Je regarderai ça sans doute ce weekend, ça a l'air rigolo et
utile.
> A la base, la gestion des paquets est justement pour le système
> entier, donc droits root nécéssaires.
C'est bien dommage :-)
Qqch que j'ai commencé à essayer, maic ça ne marche pas
"directement":
fakeroot debootstrap woody /home/toto/local
va installer une arborescence de base dans /home/totolocal,
en particulier un /home/toto/local/var/lib/dpkg, tout ça
appartenant à toto. L'idée serait ensuite de faire
fakeroot dpkg --root /home/toto/local -i foobar.deb
mais dpkg semble insister à vouloir faire un chroot() auquel
il n'a pas droit. En fait, le plus simple serait
peut-être de patcher dpkg pour mieux supporter l'option
--root sans être superutilisateur. Il n'y a a priori aucune
raison pour qu'on ne puisse pas faire ce que tu veux...
Je regarderai ça sans doute ce weekend, ça a l'air rigolo et
utile.
> A la base, la gestion des paquets est justement pour le système
> entier, donc droits root nécéssaires.
C'est bien dommage :-)
Qqch que j'ai commencé à essayer, maic ça ne marche pas
"directement":
fakeroot debootstrap woody /home/toto/local
va installer une arborescence de base dans /home/totolocal,
en particulier un /home/toto/local/var/lib/dpkg, tout ça
appartenant à toto. L'idée serait ensuite de faire
fakeroot dpkg --root /home/toto/local -i foobar.deb
mais dpkg semble insister à vouloir faire un chroot() auquel
il n'a pas droit. En fait, le plus simple serait
peut-être de patcher dpkg pour mieux supporter l'option
--root sans être superutilisateur. Il n'y a a priori aucune
raison pour qu'on ne puisse pas faire ce que tu veux...
Je regarderai ça sans doute ce weekend, ça a l'air rigolo et
utile.
Alors là je suis bluffé, comment ça fonctionne ce fakeroot ?
Comment se fait-il qu'un simple utilisateur puisse lancer dpkg via ce
fakeroot ?
C'est vrai que ce serait nettement plus agréable d'échanger des
programmes avec ses collègues en leur donnant un .deb et une commande
"dpkg -i toto.deb --root /home/toto" que de leur donner un targz et de
leur montrer comment compiler et d'allez ensuite résoudre les problèmes
de compilations...
Alors là je suis bluffé, comment ça fonctionne ce fakeroot ?
Comment se fait-il qu'un simple utilisateur puisse lancer dpkg via ce
fakeroot ?
C'est vrai que ce serait nettement plus agréable d'échanger des
programmes avec ses collègues en leur donnant un .deb et une commande
"dpkg -i toto.deb --root /home/toto" que de leur donner un targz et de
leur montrer comment compiler et d'allez ensuite résoudre les problèmes
de compilations...
Alors là je suis bluffé, comment ça fonctionne ce fakeroot ?
Comment se fait-il qu'un simple utilisateur puisse lancer dpkg via ce
fakeroot ?
C'est vrai que ce serait nettement plus agréable d'échanger des
programmes avec ses collègues en leur donnant un .deb et une commande
"dpkg -i toto.deb --root /home/toto" que de leur donner un targz et de
leur montrer comment compiler et d'allez ensuite résoudre les problèmes
de compilations...
Mais libc6 appartient à root, je ne peux pas l'enlever comme ça !
Faux !
Aucun paquet n'"appartient" au sens strict su terme à un utilisateur
et un utilisateur auquel "root" délègue ses droits de gestion de
paquets peut ajouter supprimer des paquets selon son bon vouloir.
Oui mais justement l'idée est ne pas utiliser sudo pour délivrer des
droits. Si je passe dpkg en libre d'exécution (chmod 755) pour tout le
monde, cela m'étonnerait que je puisse enlever libc6 (j'ose pas essayer
remarque...)
Certe, mais ça ne permettra jamais les upgrades ni les install
"system-wide".
Bien entendu. Cependant c'est juste pour mettre un peu d'ordre (pouvoir
installer et désinstaller proprement des logiciels) dans mes
installation locale, ce que permets Windows en passant...
Par contre je souhaitais mettre un peu d'ordre dans mes "make
install" sauvages et je voulais donc utiliser un système de
paquetages (dpkg).
A la base, la gestion des paquets est justement pour le système
entier, donc droits root nécéssaires.
A moins d'utiliser stow comme tu l'as suggérer ou refaire desp aquets
dont le rep de base est "/usr/local" par exemple au lieu de "/"
C'est bien ce que je ne comprends pas : pourquoi restreindre pour le
système entier ? pourquoi l'utilisateur dans son répertoire personnel
n'a pas le droit à une gestion des paquets ?
Stow n'atteindra jamais la facilité de gestion d'un dpkg sans parler de
son fonctionnement "bizarre" par répertoire et lien symbolique, mais en
derniers recours je pense l'utiliser.
J'essaye de trouver une solution générique que je pourrais recommander à
n'importe qui, donc la solution de demander gentiment à l'administrateur
ne me plait pas trop.
J'avais déjà gagné des points avec mes collègues en leur montrant qu'il
était possible d'installer tout et n'importe quoi en local sous Linux
sans qu'une quelconque base de registre verrouillée ne viennent nous
embêter. Par contre sous Windows il existent des logiciels "propres" qui
veulent bien s'installer en local, ce que ne permet pas Linux (hormis
via des "make install prefix=/home/toto" mais c'est vite le bordel).
Je ne sais pas si sous Red Hat/Mandrake c'est pareil ?
On peut utiliser rpm lorsque l'on est pas root ?
Merci pour tes recommandations mais je ne peux vraiment pas utiliser
sudo...
Mais libc6 appartient à root, je ne peux pas l'enlever comme ça !
Faux !
Aucun paquet n'"appartient" au sens strict su terme à un utilisateur
et un utilisateur auquel "root" délègue ses droits de gestion de
paquets peut ajouter supprimer des paquets selon son bon vouloir.
Oui mais justement l'idée est ne pas utiliser sudo pour délivrer des
droits. Si je passe dpkg en libre d'exécution (chmod 755) pour tout le
monde, cela m'étonnerait que je puisse enlever libc6 (j'ose pas essayer
remarque...)
Certe, mais ça ne permettra jamais les upgrades ni les install
"system-wide".
Bien entendu. Cependant c'est juste pour mettre un peu d'ordre (pouvoir
installer et désinstaller proprement des logiciels) dans mes
installation locale, ce que permets Windows en passant...
Par contre je souhaitais mettre un peu d'ordre dans mes "make
install" sauvages et je voulais donc utiliser un système de
paquetages (dpkg).
A la base, la gestion des paquets est justement pour le système
entier, donc droits root nécéssaires.
A moins d'utiliser stow comme tu l'as suggérer ou refaire desp aquets
dont le rep de base est "/usr/local" par exemple au lieu de "/"
C'est bien ce que je ne comprends pas : pourquoi restreindre pour le
système entier ? pourquoi l'utilisateur dans son répertoire personnel
n'a pas le droit à une gestion des paquets ?
Stow n'atteindra jamais la facilité de gestion d'un dpkg sans parler de
son fonctionnement "bizarre" par répertoire et lien symbolique, mais en
derniers recours je pense l'utiliser.
J'essaye de trouver une solution générique que je pourrais recommander à
n'importe qui, donc la solution de demander gentiment à l'administrateur
ne me plait pas trop.
J'avais déjà gagné des points avec mes collègues en leur montrant qu'il
était possible d'installer tout et n'importe quoi en local sous Linux
sans qu'une quelconque base de registre verrouillée ne viennent nous
embêter. Par contre sous Windows il existent des logiciels "propres" qui
veulent bien s'installer en local, ce que ne permet pas Linux (hormis
via des "make install prefix=/home/toto" mais c'est vite le bordel).
Je ne sais pas si sous Red Hat/Mandrake c'est pareil ?
On peut utiliser rpm lorsque l'on est pas root ?
Merci pour tes recommandations mais je ne peux vraiment pas utiliser
sudo...
Mais libc6 appartient à root, je ne peux pas l'enlever comme ça !
Faux !
Aucun paquet n'"appartient" au sens strict su terme à un utilisateur
et un utilisateur auquel "root" délègue ses droits de gestion de
paquets peut ajouter supprimer des paquets selon son bon vouloir.
Oui mais justement l'idée est ne pas utiliser sudo pour délivrer des
droits. Si je passe dpkg en libre d'exécution (chmod 755) pour tout le
monde, cela m'étonnerait que je puisse enlever libc6 (j'ose pas essayer
remarque...)
Certe, mais ça ne permettra jamais les upgrades ni les install
"system-wide".
Bien entendu. Cependant c'est juste pour mettre un peu d'ordre (pouvoir
installer et désinstaller proprement des logiciels) dans mes
installation locale, ce que permets Windows en passant...
Par contre je souhaitais mettre un peu d'ordre dans mes "make
install" sauvages et je voulais donc utiliser un système de
paquetages (dpkg).
A la base, la gestion des paquets est justement pour le système
entier, donc droits root nécéssaires.
A moins d'utiliser stow comme tu l'as suggérer ou refaire desp aquets
dont le rep de base est "/usr/local" par exemple au lieu de "/"
C'est bien ce que je ne comprends pas : pourquoi restreindre pour le
système entier ? pourquoi l'utilisateur dans son répertoire personnel
n'a pas le droit à une gestion des paquets ?
Stow n'atteindra jamais la facilité de gestion d'un dpkg sans parler de
son fonctionnement "bizarre" par répertoire et lien symbolique, mais en
derniers recours je pense l'utiliser.
J'essaye de trouver une solution générique que je pourrais recommander à
n'importe qui, donc la solution de demander gentiment à l'administrateur
ne me plait pas trop.
J'avais déjà gagné des points avec mes collègues en leur montrant qu'il
était possible d'installer tout et n'importe quoi en local sous Linux
sans qu'une quelconque base de registre verrouillée ne viennent nous
embêter. Par contre sous Windows il existent des logiciels "propres" qui
veulent bien s'installer en local, ce que ne permet pas Linux (hormis
via des "make install prefix=/home/toto" mais c'est vite le bordel).
Je ne sais pas si sous Red Hat/Mandrake c'est pareil ?
On peut utiliser rpm lorsque l'on est pas root ?
Merci pour tes recommandations mais je ne peux vraiment pas utiliser
sudo...
