Re: Two packages with different version, from the same source
On Tue, Feb 07, 2006 at 04:47:30AM -0200, Nelson A. de Oliveira wrote: > Hi mentors! > > I have a doubt. > > I am creating a package of a Firefox/Mozilla extension. Upstream > author reselases two .xpi files, one for Firefox and another for > Mozilla. Since they are small, I was wanting to create just one source > package (including both .xpi files) and generate two binary packages > (one package for Firefox and the other for Mozilla). > > The problem is that upsteram author released a new version of the .xpi > just for Firefox. > The extension for Firefox is on version 1.4 and of Mozilla is on version 1.3.2 > > What is the best solution for my problem? > Put both .xpi files on the same .orig.tar.gz and create two binary If at all possibly, the .orig.tar.gz should be pristine. The only reasons why this shouldn't be so is if one of: . the upstream tarball is nonfree, but can still produce useful packages after being stripped of nonfree material . there is no upstream tarball . there is a massive space savings by cleaning binaries out of the upstream tarball > packages, using dh_gencontrol with the -v flag? If I make this and, It seems that you would need to use -uv or something, see dh_gencontrol(1). > Or do I create two source packages? This may be best, especially if it gets you 2 pristine tarballs, and if it would be otherwise impossible. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing former conffiles
On Tue, Feb 07, 2006 at 11:47:49PM +0100, Bas Wijnen wrote: > On Tue, Feb 07, 2006 at 12:28:39AM -0800, Don Armstrong wrote: > > On Tue, 07 Feb 2006, Frank K?ster wrote: > > > Don Armstrong <[EMAIL PROTECTED]> wrote: > > > > Just a word of caution here: If the administrator has modified the > > > > file, you should not rename or move it, as they may know better > > > > than you what they're doing. A proper course of action would be > > > > warning them, and/or offering to remove the files in question via > > > > debconf. > > > If I know that the file will no longer be read at all, there's no > > > point in pretending that it still have an effect. Renaming it makes > > > this completely clear. > > Right. The problem is that it's not always easy to know if the file > > will no longer be read at all; you can't assume that the administrator > > has left in place your default configuration system. [Likewise for > > failure modes on the presence of an obsolete configuration file; > > unless you know for certain that it will fail, you should give the > > administrator some way to override your guess.] > The package is a dummy transition package. When this version of gnocatan is > installed, no gnocatan config files will be read at all anymore. It might > have been a good idea to try and convert it into a pioneers config file (the > new name of the package), but as long as the name includes "gnocatan", it's > not going to have any effect, since there are no binaries in the gnocatan-* > packages anymore (well, except this maintainer script). > Would that mean it's ok to remove it? Or should I better rename it so they > can use it to convert to a pioneers file by hand? Perhaps that's the best... > I could make a NEWS message about that as well. I think the right thing to do here is to simply remove it if we can determine that it's unmodified. Well, really, I think the right thing is for *dpkg* to remove it if it can determine that it's unmodified; this is bug #330256. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Removing former conffiles
On Tue, Feb 07, 2006 at 12:28:39AM -0800, Don Armstrong wrote: > On Tue, 07 Feb 2006, Frank K?ster wrote: > > Don Armstrong <[EMAIL PROTECTED]> wrote: > > > Just a word of caution here: If the administrator has modified the > > > file, you should not rename or move it, as they may know better > > > than you what they're doing. A proper course of action would be > > > warning them, and/or offering to remove the files in question via > > > debconf. > > > > If I know that the file will no longer be read at all, there's no > > point in pretending that it still have an effect. Renaming it makes > > this completely clear. > > Right. The problem is that it's not always easy to know if the file > will no longer be read at all; you can't assume that the administrator > has left in place your default configuration system. [Likewise for > failure modes on the presence of an obsolete configuration file; > unless you know for certain that it will fail, you should give the > administrator some way to override your guess.] The package is a dummy transition package. When this version of gnocatan is installed, no gnocatan config files will be read at all anymore. It might have been a good idea to try and convert it into a pioneers config file (the new name of the package), but as long as the name includes "gnocatan", it's not going to have any effect, since there are no binaries in the gnocatan-* packages anymore (well, except this maintainer script). Would that mean it's ok to remove it? Or should I better rename it so they can use it to convert to a pioneers file by hand? Perhaps that's the best... I could make a NEWS message about that as well. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: What to do if the upstream keeps debian directory in original tarball?
On Tuesday 07 February 2006 13:15, Jari Aalto wrote: > Is the upstream using a VCS? (Version control software)? > > 1) If he is, can he grant you a direct write access. That would be the > easiest. > > 2) Can he be persuaded into using distributed SCM[1]? That way both of > you can synchronize at will No, he is not using a VCS. I sort of solved the problem already, thanks. Stan
RE: RFC: PyKaraoke
--- Miriam Ruiz <[EMAIL PROTECTED]> wrote: > Only the frontend seems to be using libwxgtk-python, so I'm planning to > separate it into two different binary packages, one with the command line > programs (and less dependencies, no wx) and another one, depending on it, > with > the frontend. I've split the package into two, as I said. I have a problem with lintian anyway, the manpage for all the programs is the same, with links. Thus, the gui program does not include its own manpage, as it is included in the command-line package, which is required. Lintian gives a warning anyway. May I override it? Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do if the upstream keeps debian directory in original tarball?
Stan Vasilyev <[EMAIL PROTECTED]> writes: > I have a situation with a Debian package xdialog: > http://packages.qa.debian.org/x/xdialog.html > > The upstream author, Thierry Godefroy <[EMAIL PROTECTED]>, insists on keeping > the debian changes inside the upstream tarball, orig.tar.gz. This > complicates the development process. First of all, when he makes a > new version of xdialog, he sends it to the Debian maintainer (me). I > then have to make changes to the debian directory and send him the > changes. Finally, he releases the new upstream with Debian changes > already included. Is the upstream using a VCS? (Version control software)? 1) If he is, can he grant you a direct write access. That would be the easiest. 2) Can he be persuaded into using distributed SCM[1]? That way both of you can synchronize at will Jari [1] http://bazaar-ng.org/ http://bazaar.canonical.com/IntroductionToBzr And excellent Python based, very easy use, 2nd generation distributed version control system is bazaar-ng. The simple workflow is: $ bzr init $ bzr add ... $ bzr ci -m "My chnages" ... $ bzr pull -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing former conffiles
On Tue, 07 Feb 2006, Frank Küster wrote: > Don Armstrong <[EMAIL PROTECTED]> wrote: > > On Tue, 07 Feb 2006, Frank Küster wrote: > >> Don Armstrong <[EMAIL PROTECTED]> wrote: > >> > >> > Right. The problem is that it's not always easy to know if the file > >> > will no longer be read at all; you can't assume that the administrator > >> > has left in place your default configuration system. > >> > >> Of course the maintainer should know their package. If the binary reads > >> a configuration file in /usr/share/bla, and in the old version there was > > > > This would be a problem. > > Why? What problem? You've now got a conffile in a location which is not /etc, namely /var/lib/bla, which cannot be overridden by the administrator. Instead, I'd suggest having the symlink in /usr/share/bla pointing to /etc/bla.cnf which then in the default install is a symlink to /var/lib/bla or whatever is appropriate; if the user has modified the configuration file, you don't stick in the symlink. If the user hasn't, you put in the symlink. [Of course, ideally you'd have a configuration file language that would enable you to just include the conf.d directly... but that may not always be possible.] Don Armstrong -- "The trouble with you, Ibid" he said, "is that you think you're the biggest bloody authority on everything" -- Terry Pratchet _Pyramids_ p146 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Removing former conffiles
On Tue, Feb 07, 2006 at 11:35:01AM -0800, Don Armstrong wrote: > On Tue, 07 Feb 2006, Frank K?ster wrote: > > Don Armstrong <[EMAIL PROTECTED]> wrote: > > > > > Right. The problem is that it's not always easy to know if the file > > > will no longer be read at all; you can't assume that the administrator > > > has left in place your default configuration system. > > > > Of course the maintainer should know their package. If the binary reads > > a configuration file in /usr/share/bla, and in the old version there was > > This would be a problem. Not really, just nonideal; policy even covers it: |10.7.2 Location | |Any configuration files created or used by your package must reside in |/etc. If there are several, consider creating a subdirectory of /etc |named after your package. | |If your package creates or uses configuration files outside of /etc, |and it is not feasible to modify the package to use /etc directly, put |the files in /etc and create symbolic links to those files from the |location that the package requires. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing former conffiles
Don Armstrong <[EMAIL PROTECTED]> wrote:
> On Tue, 07 Feb 2006, Frank Küster wrote:
>> Don Armstrong <[EMAIL PROTECTED]> wrote:
>>
>> > Right. The problem is that it's not always easy to know if the file
>> > will no longer be read at all; you can't assume that the administrator
>> > has left in place your default configuration system.
>>
>> Of course the maintainer should know their package. If the binary reads
>> a configuration file in /usr/share/bla, and in the old version there was
>
> This would be a problem.
Why? What problem?
>> a symlink from /usr/share/bla/bla.conf to /etc/bla/bla.conf, but now
>> the file is generated from files in /etc/bla/conf.d, sits in
>> /var/lib/bla, and the symlink points there, it's safe to assume that
>> /etc/bla/bla.conf is unused.
>
> The issue here is that you've suddenly changed the way the system
> works, so perhaps the proper method is to move /etc/blah/bla.conf into
> /etc/bla/conf.d/ instead; at the very least you should move the users
> configuration away into a backup position or something rather than
> deleting it if they have made changes.
I never talked about deleting it. In some cases we indeed managed to
transfer it. There might be others where it isn't possible.
It might also be that the binary simply stops looking for that
particular conffile because the configuration options are obsolete.
>> In some cases, yes. We have cases in teTeX where there are only two
>> alternatives: Either accept the change, or not install the
>> debianized package at all and go for /usr/local/ instead.
>
> That seems like a bug to me; it may not be easy to fix in tetex, but
> it's definetly not the ideal situtation for a package.
Go ahead and submit bugs, and we'll discuss whether there's a better
solution. One example:
TeX input files are found in any path ("TEXMF tree") defined in the
TEXMF variable. We had to move teTeX's files from /usr/share/texmf
(which continues to be a TEXMF tree for other packages) into
/usr/share/texmf-tetex, and consequently we need to add this new tree
into the list in the variable TEXMF.
If the user refuses this change upon upgrade, what other choice do we
have? We check for it in postinst and bail out before trying to do any
configure work which will fail for sure.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Re: Removing former conffiles
On Tue, 07 Feb 2006, Frank Küster wrote: > Don Armstrong <[EMAIL PROTECTED]> wrote: > > > Right. The problem is that it's not always easy to know if the file > > will no longer be read at all; you can't assume that the administrator > > has left in place your default configuration system. > > Of course the maintainer should know their package. If the binary reads > a configuration file in /usr/share/bla, and in the old version there was This would be a problem. > a symlink from /usr/share/bla/bla.conf to /etc/bla/bla.conf, but now > the file is generated from files in /etc/bla/conf.d, sits in > /var/lib/bla, and the symlink points there, it's safe to assume that > /etc/bla/bla.conf is unused. The issue here is that you've suddenly changed the way the system works, so perhaps the proper method is to move /etc/blah/bla.conf into /etc/bla/conf.d/ instead; at the very least you should move the users configuration away into a backup position or something rather than deleting it if they have made changes. > In some cases, yes. We have cases in teTeX where there are only two > alternatives: Either accept the change, or not install the > debianized package at all and go for /usr/local/ instead. That seems like a bug to me; it may not be easy to fix in tetex, but it's definetly not the ideal situtation for a package. Don Armstrong -- "The question of whether computers can think is like the question of whether submarines can swim." -- Edsgar Dijkstra http://www.donarmstrong.com http://rzlab.ucr.edu
Re: RFC: PyKaraoke
Miriam Ruiz <[EMAIL PROTECTED]> wrote: > PyKaraoke is a free karaoke player written in Python. If that's meant to be the start of the long description, please drop the "written in Python", because it's not interesting, and for those who want to know that nevertheless, the information is in the dependency fields. HTH, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
Don Armstrong <[EMAIL PROTECTED]> wrote: > Right. The problem is that it's not always easy to know if the file > will no longer be read at all; you can't assume that the administrator > has left in place your default configuration system. Of course the maintainer should know their package. If the binary reads a configuration file in /usr/share/bla, and in the old version there was a symlink from /usr/share/bla/bla.conf to /etc/bla/bla.conf, but now the file is generated from files in /etc/bla/conf.d, sits in /var/lib/bla, and the symlink points there, it's safe to assume that /etc/bla/bla.conf is unused. > [Likewise for > failure modes on the presence of an obsolete configuration file; > unless you know for certain that it will fail, you should give the > administrator some way to override your guess.] In some cases, yes. We have cases in teTeX where there are only two alternatives: Either accept the change, or not install the debianized package at all and go for /usr/local/ instead. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
RFS: opendchub --- hub clone for Direct Connect (DC) network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all! As some of you may already know from -devel, I've adopted opendchub recently from Grzegorz Prokopski (gadek), and now I've finished packaging the new version which fixes a few bugs and updates the autotools stuff. As usual, here's the standard stuff for the RFS: Source: opendchub License: GPL Section: net Priority: optional Maintainer: Zak B. Elep <[EMAIL PROTECTED]> Build-Depends: autotools-dev, cdbs, debhelper (>= 5), libperl-dev, libcap-dev Standards-Version: 3.6.2 Description: hub clone for DC (Direct Connect P2P network) Open DC hub is a Unix/Linux version of the hub software for the Direct Connect network. Direct Connect is a file sharing network made up by hubs, to which clients can connect. It offers offers peer-based file-sharing. In practise it works better than gnutella and other similar systems as it allows dc hubs (servers) administators to require clients to share specified amount of data. The amount is usually based on type of client's connection and it is used not to hurt or exclude anybody but to make file sharing "fair play". . This version supports most of the features of the official hub. Some of the currently supported features are: * Searching for files, * Connecting to users, both in active and passive mode, * Messaging in open chat, * Private messaging, * Registering users, * Kicking users (for OP:s), * Banning users (for Admins), * Uploading hub address and description to public hub list, * Hublinking, which makes it possible to search on other hubs connnected to the network. . The hub is run as a daemon, i.e, it runs in the background. It's administrated through a tcp connection, for example with telnet, which makes it possible to administer remotely, given that the user has the administration password. . Homepage: http://opendchub.sourceforge.net The package is available at mentors.[0] [0] http://mentors.debian.net/debian/pool/main/o/opendchub/ Sponsors, I hope for your quick response. Thanks in advance! :D Cheers, Zakame - -- Zak B. Elep || http://zakame.spunge.org [EMAIL PROTECTED] || [EMAIL PROTECTED] 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD6GF0V4ex/fpThR0RAl2SAJ9dEeJIGuF3RpCt1SGoit2Pg8urCwCfV/C0 iWtYj0ld0MubPZa6oUOTaA0= =pRgg -END PGP SIGNATURE-
Re: Removing former conffiles
On Tue, 07 Feb 2006, Frank Küster wrote: > Don Armstrong <[EMAIL PROTECTED]> wrote: > > Just a word of caution here: If the administrator has modified the > > file, you should not rename or move it, as they may know better > > than you what they're doing. A proper course of action would be > > warning them, and/or offering to remove the files in question via > > debconf. > > If I know that the file will no longer be read at all, there's no > point in pretending that it still have an effect. Renaming it makes > this completely clear. Right. The problem is that it's not always easy to know if the file will no longer be read at all; you can't assume that the administrator has left in place your default configuration system. [Likewise for failure modes on the presence of an obsolete configuration file; unless you know for certain that it will fail, you should give the administrator some way to override your guess.] Don Armstrong -- A people living under the perpetual menace of war and invasion is very easy to govern. It demands no social reforms. It does not haggle over expenditures on armaments and military equipment. It pays without discussion, it ruins itself, and that is an excellent thing for the syndicates of financiers and manufacturers for whom patriotic terrors are an abundant source of gain. -- Anatole France http://www.donarmstrong.com http://rzlab.ucr.edu
RFC: PyKaraoke
PyKaraoke is a free karaoke player written in Python. You can use it to play your collection of CDG, MIDI and MPEG karaoke songs. Upstream homepage is at http://www.kibosh.org/pykaraoke/ PyKaraoke is actually a GUI frontend which controls three libraries, pycdg for CDG files, pykar for MIDI/KAR files and pympg for MPEG files. If you do not wish to use the GUI you can actually start a player directly from the command-line (or by associating file-types in your operating system). Prerequisites for using the program are: python python-pygame libwxgtk-python python-numeric Only the frontend seems to be using libwxgtk-python, so I'm planning to separate it into two different binary packages, one with the command line programs (and less dependencies, no wx) and another one, depending on it, with the frontend. My current packages are at http://baby.yi.org/packages/pykaraoke/ . I guess the links to the program should go to /usr/games instead of /usr/bin, and I'm not sure whether /usr/lib/python is the best place to put the program files, as probably /usr/share/python would fit best, but upstream choose to put them there. Maybe I should ask him about it. I'd be glad to receive comments about the package or about the doubts I have commented. Lots of thanks, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing former conffiles
Don Armstrong <[EMAIL PROTECTED]> wrote: > On Mon, 06 Feb 2006, Frank Küster wrote: >> - if it is changed, either keep it and insert a comment at its >> beginning that it is unused, or move/rename it. In all cases where >> the file's presence could have a bad effect, I renamed or moved >> it. > > Just a word of caution here: If the administrator has modified the > file, you should not rename or move it, as they may know better than > you what they're doing. A proper course of action would be warning > them, and/or offering to remove the files in question via debconf. If I know that the file will no longer be read at all, there's no point in pretending that it still have an effect. Renaming it makes this completely clear. If it's just a "the file is no longer needed", then of course I need not do anything, but a warning, debconf question, or just an entry in NEWS.Debian would be good. There's yet an other case: If the postinst script finds that a conf(iguration) file has a setting that will break later postinst action, and result in an unconfigured package, then it should fail right away and give an explanation (and not try to proceed and fail later with a much less understandable error message). > Additionally, you should check to make sure whether you're upgrading > from a version after this transition; if that's the case, you > shouldn't rename/delete either. Yes, that should always be done. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
Justin Pryzby <[EMAIL PROTECTED]> wrote: > On Mon, Feb 06, 2006 at 10:02:06PM +0100, Frank K?ster wrote: >> Bas Wijnen <[EMAIL PROTECTED]> wrote: >> >> > The question is, how do I solve this? Should I forcefully remove >> > the conffile before calling update-rc.d? It feels really bad to >> > remove files from /etc in maintainer scripts, but perhaps it's the >> > right thing to do... > >> - if the file is unchanged, remove it > Even changed files are removed on purge. Yes, of course - I should have been more clear. What I wrote is done in preinst. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
