date:20090803

Nettoyer un répertoire plein de .deb ?

2009-08-03 Thread Éric Seigne


Bonjour,
es-ce qu'il existe une commande rapide et efficace pour faire le ménage 
dans un dossier plein de paquets .deb pour ne garder que ceux dont les 
numéros de versions sont les plus récents ?


Par exemple j'ai

package_1.2.0-0_i386.deb
package_1.2.0-1_i386.deb
package_1.3.1-0_i386.deb
package_1.3.4-6_i386.deb
package_1.3.4-7_i386.deb

et je ne veux garder que le dernier ... y a ça, sans se lancer dans des 
outils de gestion de dépots ?


Merci d'avance,
Éric

--
   -- ABULEDU A 10 ANS ... www.abuledu.org --

Éric Seigne - Directeur| eric.sei...@ryxeo.com
RyXéo SARL | http://www.ryxeo.com
21 avenue M. et E. Dulout  | tel +33 6 987 444 01
33600 Pessac - FRANCE  | fax +33 9 56 606 607



--
To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Nettoyer un répertoir e plein de .deb ?

2009-08-03 Thread Pierre Habouzit

On Mon, Aug 03, 2009 at 09:56:00PM +0200, Pierre Habouzit wrote:
 On Mon, Aug 03, 2009 at 04:02:43PM +0200, Éric Seigne wrote:
  Bonjour,
  es-ce qu'il existe une commande rapide et efficace pour faire le
  ménage dans un dossier plein de paquets .deb pour ne garder que ceux
  dont les numéros de versions sont les plus récents ?
  
  Par exemple j'ai
  
  package_1.2.0-0_i386.deb
  package_1.2.0-1_i386.deb
  package_1.3.1-0_i386.deb
  package_1.3.4-6_i386.deb
  package_1.3.4-7_i386.deb
  
  et je ne veux garder que le dernier ... y a ça, sans se lancer dans
  des outils de gestion de dépots ?
  
  Merci d'avance,
  Éric

Sauf que ça ne marche pas... parce que je pars du principe que le
file-name contient l'époch ce qui est généralement faux...

Le fix suivant devrait corriger ça:
 
 #!/bin/sh
 
 dry_run=
 
 doit() {
 $dry_run $@
 }
 
 while test $# != 0; do
 case $1 in
 -n) dry_run=echo ;;
 --) shift; break; ;;
 *)  break ;;
 esac
 shift
 done
 
 if test $# != 1; then
 echo usage: foo.sh directory 21
 exit 1
 fi
 
 cd $1
 
 for p in $(ls *.deb|sed -e 's/_.*//'|sort -u); do
 keep=
+keep_v=
 for v in $(ls ${p}_*.deb | sed -e 
's/^[^_]*_\([^_]*\)_[^_]*\.deb$/\1/'); do
+ver=$(dpkg --info binutils-dev_2.19.51.20090704-1_amd64.deb|sed -ne 
'/Version: /{s/ *Version: *//p;q}')
 if test -z $keep; then
 keep=$v
+keep_v=$ver
-elif dpkg --compare-versions $keep gt $v; then
+elif dpkg --compare-versions $keep_v gt $ver; then
 doit rm -f ${p}_${v}_*.deb
 else
 doit rm -f ${p}_${keep}_*.deb
 keep=$v
+keep_v=$ver
 fi
 done
 done


Et sinon la bonne manière est d'utiliser dpkg --info et de prendre le
Package: et Version:, de trier pour chaque Package: unique par ordre de
Version: selon dpkg --compare-versions, et de ne conserver que le
dernier de chaque. Je pense que dpkg --compare-versions est accessible
depuis perl-apt (si ça existe) et je suis sur que c'est accessible
depuis python-apt pour l'utiliser dans apt-listchanges. Mais j'ai la
flemme d'écrire le script en question.


-- 
Intersec http://www.intersec.com
Pierre Habouzit pierre.habou...@intersec.com
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


signature.asc
Description: Digital signature

Re: maybe a problem with sid branch

2009-08-03 Thread Muammar El Khatib

Hi,

2009/8/1 Leinier Cruz Salfran salfra...@ipigto.rimed.cu:
 I disagree with you on this point .. where is success? in a civilized
 discussion on the proposal and the exchange of ideas .. if we discover
 that there is a problem why we will not publish this list, for example,
 although it is obvious that this is a problem of dependencies and is the
 branch where are shown all recent changes and new packages that have
 probability of failure? .. I think if we want development we can not be
 put obstacles .. that is my humble opinion


I understand your point, but you should be aware of the definition of this
Debian branch:

1) http://www.debian.org/releases/unstable/
2) http://en.wikipedia.org/wiki/Debian#Distributions

As you can see, in 1) there says:

sid is subject to massive changes and in-place library updates. This can
result in a very unstable system which contains packages that cannot be
installed due to missing libraries, dependencies that cannot be fulfilled etc.

So, in spite of your correct rationale about this, sid may have problems related
to _minor_ dependencies and this is the case (because of its changing-nature).
This is a common problem when trying to create a base.tgz in pbuilder. Just try
again later.

Regards,
-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 127029F1
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: What to do with (packages like) Blender?

2009-08-03 Thread Ben Finney

Christian Perrier bubu...@debian.org writes:

 Just drop that blender thing and announce this loudly enough,
 preferrably by coordinating with other distro maintainers. That will
 eventually trigger a fork from people who have a more collaborative
 way of thinking.

This coordination would probably best be done via
URL:http://lists.freedesktop.org/mailman/listinfo/distributions the
Freedesktop Distributions collaboration forum.

-- 
 \   “[W]hoever is able to make you absurd is able to make you |
  `\unjust.” —Voltaire |
_o__)  |
Ben Finney


pgpueMipl1kGF.pgp
Description: PGP signature

Re: What to do with (packages like) Blender?

2009-08-03 Thread Hendrik Sattler


Zitat von Christian Perrier bubu...@debian.org:


Quoting Cyril Brulebois (k...@debian.org):


4) http://article.gmane.org/gmane.comp.video.blender.devel/19895

Patch to add support for system-wide FTGL. I kind of get flamed for
thinking about using something else than what blender provides. And
who cares about shared libraries anyway, they are dangerous. If you
want to have a good idea of what blender folks think about being
distributed, you want to read that thread.



That one shows the problem clearly enough. Blender folks are not
interested in using system-wide libs *at all*. They apparently prefer
using their own private (and buggySam made the point very clear)
version of a library, on the vague assumption that, as libraries
change their API without warning, they're bad.

I'm anything but a specialist in this area, but my understanding is
that this is what sonames are about..:-). Anyway, in 2009, such
reasoning isawfully flawed.

Just drop that blender thing and announce this loudly enough,
preferrably by coordinating with other distro maintainers. That will
eventually trigger a fork from people who have a more collaborative
way of thinking. After all, to my understanding, this blender stuff is
kinda widely used in 3D modelling, right?


I read that discussion in a different tone as it mostly refers to the  
FTGL thing. They made changes to the library that are needed and  
blender would not work correctly without those.
The patch doesn't ensure that the system version of that library  
includes those changes, it doesn't even check for known good versions.  
This was the main complaint especially since there is no release of  
FTGL with those changes, yet! So they cannot expect for everyone (and  
there are other distributions, too) to use _unreleased_ versions of a  
library (release candidates are not a release).
Together, these are valid points for linking a private copy that was  
tested against. They didn't say anything against having to update that  
copy.


Additionally, not all upstream library developers are aware of how  
SONAMEs are to be handled (and maybe they got burned by this before).
Maybe because libtool's description of SONAMEs is way to complicated  
(what insane person wrote this?) and limited, and because other  
popular systems don't support this.
After all, users only see bugs in the frontend, not in the libraries  
behind it.
And there are lots of other projects, too, that include private copies  
of libraries (e.g. mplayer). This was even the proposed way for some  
GNU stuff some time ago!


HS



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Approaching non-integratable software, was: What to do with (packages like) Blender?

2009-08-03 Thread Reinhard Tartler


[ moving discussion to -project. Please follow up on -devel if you are
  contributing to the technical discussion and -project for the project
  wide parts ]

Cyril Brulebois k...@debian.org writes:

 It's been a while and I'm now really wondering what to do with
 Blender. So that everyone can understand, I'm going to try and sum up
 what I'm facing. 

It seems to me that blender is not unique in this regard. There is more
software than just blender that prefers to not be integrated into a
distribution properly, but rather prefers to retain exact control of
(external) libraries that are being included into their source and
binaries. Another characteristic is that they focus on binary
redistribution, and frown upon users that grab the source and compile
themselves.

blender is surely not alone. Other prominent, yet unpackaged pieces of
software would be handbrake [1], or XBMC[2]. For handbrake the
solution so far has been to not package it at all [3], xbmc is having
a hard time working on the source to use system libraries.

I think it would be sad to not include such packages at all. Knowing
proper integration into Debian as distribution is not going to work, how
about integrating them as add-on software? I imagine the following
approach:

 - software gets installed into /opt, so that file conflicts are less
   likely and the software status is visible to the users

 - packages go to an special section of the archive extra. That
   section would be similar to contrib: autobuilt, PTS and BTS
   coverage, no security support .

 - package can easily be moved to main after it has matured to use
   system libraries.

In some ways, this extra repository can be seen as staging or preview
repository. We wouldn't need to provide the tedious and laboratory QA
tasks concerning security and integration efforts, but could still
provide our users with such software.


Footnotes:
[1] http://handbrake.fr
[2] http://www.xbmc.org/wiki/?title=XBMC_for_Linux_port_project
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456165


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Orphaning debmirror

2009-08-03 Thread Goswin von Brederlow

Siggy Brentrup deb...@psycho.i21k.de writes:

Hi,

sorry for the late reply, we were celebrating my wife's birthday at
the seaside until yesterday late in the evenign.

On Fri, Jul 31, 2009 at 17:53 +0100, Steve Kemp wrote:
On Fri Jul 31, 2009 at 18:47:58 +0200, Siggy Brentrup wrote:

Who wrote debmirror? Without installing I can't find out since
only maintainers are listed in the PTS.

Look at the copyright file:

e.g.

http://packages.debian.org/changelogs/pool/main/d/debmirror/debmirror_20070123/debmirror.copyright

Thanks for this link, imbecile me to overlook that while on the
debmirror page.

I'm asking because
there's a lot of perl code in Debian I wouldn't even think about
touching due to the author's programming style.

If you only care about the style why not actually download it
and examine it?

because a one line answer containg certain names would have saved me
the hassle to do exactly what you are asking me to do. In the dark
ages I used to have to understand their code, it took much more time
than I usally want to invest; so if I have a choice: no thanks.

Thanks
Siggy
--
Please don't Cc: me when replying, I might not see either copy.
bsb-at-psycho-dot-informationsanarchistik-dot-de
or:bsb-at-psycho-dot-i21k-dot-de
O ascii ribbon campaign - stop html mail - www.asciiribbon.org

1 2 >

1 - 100 of 116 matches

Mail list logo