Re: bitbucket is lock in? (was: Re: Packaging on GitHub ?)
* Martin Bagge / brother [2012-05-29 21:01 +0200]: > On Tue, 29 May 2012, Brian May wrote: > > >I don't see the problem, github is just a hosting provider. Unlike, > >say Bitkeeper, ... > > Can you elaborate on the bitbucket case there? How am I not allowed > to do a git clone from my git repo on bitbucket ... "Bitkeeper" is proprietary software, "Bitbucket" is a hosting service. Besides the "Bit" in their name, they have not much in common. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120529193418.ga...@furrball.stateful.de
Re: on the use of chmod/chown in maintainer scripts
* Andreas Barth [2012-05-13 11:06 +0200]:
> * Russ Allbery (r...@debian.org) [120512 23:06]:
> > Charles Plessy writes:
> >
> > > Unless we expect that two different binary packages that can be
> > > co-installed will distribute the same directory under different
> > > ownership or permissions for a good reason, why not simply let dpkg
> > > apply ownership and permissions found in data.tar.{gz|bz2|xz},
> >
> > Usually because the UID is dynamically assigned and the user is created in
> > the postinst, so there's no way for dpkg do do this at unpack.
> >
> > You would need to apply permissions by name, not UID/GID, and you would
> > need to create all users in preinst prior to unpack, which would require
> > Pre-Depends on adduser with all the complexity that entails. I haven't
> > thought through that path to see if there are any other problems.
>
> Wouldn't it be sensible to describe which user(s) a programm needs as
> well not by "adduser $user" but in a more abstract syntax
I agree.
> and let dpkg handle all of that?
This doesn't look like a task that should be done by dpkg itself;
instead debhelper or dpkg-maintscript-helper could be used.
Carsten
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120513101924.ga19...@furrball.stateful.de
Re: Fwd: Re: Bug#614907: nodejs/node command conflict: why can't we have both?
* Don Armstrong [2012-05-03 16:08 -0700]: > On Fri, 04 May 2012, Carsten Hey wrote: > > Should not at least @debian.org addresses by default be whitelisted > > on the tech-ctte list? > > Sign your e-mail if you want it to go through or subscribe or send the > mail through the BTS. The need to sign does not solve this problem in general, but using the BTS does, thanks. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503231239.gq17...@furrball.stateful.de
Fwd: Re: Bug#614907: nodejs/node command conflict: why can't we have both?
Should not at least @debian.org addresses by default be whitelisted on the tech-ctte list? - Forwarded message from debian-ctte-requ...@lists.debian.org - Date: Thu, 3 May 2012 22:33:51 + (UTC) From: debian-ctte-requ...@lists.debian.org To: cars...@debian.org Subject: Re: Re: Bug#614907: nodejs/node command conflict: why can't we have both? You are not subscribed to this list, so your submission was rejected. Please subscribe to the list first and then repost your message. A copy of your submission is included below. --- * Jonathan Nieder [2012-05-02 18:56 -0500]: > Jonathan Nieder wrote: > > > I'd be happy to talk about work so far, transition plans, > > complications and possible ways forward in a separate message. > > This seems like a long shot, but the maintainers of both packages > seemed to like it, so let's give mentioning it a try: > > Assuming we go through with the transition, no package in Debian would > use the "node" command. At this point, as far as transition plans go, > it doesn't matter what the "node" command does --- it could have some > other effect entirely. > > Now what if we provide both /usr/bin/node and /usr/sbin/node? Bash uses /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin as path if $PATH is not set, so /usr/sbin before /usr/bin in the path is not that unlikely. A user installs node to get node.js and notices that it is the wrong program, then he installs the correct package nodejs and notices that the command node still does not what's expected. Does not sound like a solution to me. > As Marco mentioned[1] on debian-devel, there is nothing but our > stubbornness and good sense stopping us from doing that. "I want to do packet radio and to programm in node.js on my computer, why is this not possible with Debian." Carsten - End forwarded message - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503223819.gp17...@furrball.stateful.de
Re: Node.js and it's future in debian
* Patrick Ouellette [2012-05-01 16:55 -0400]: > I was under the impression that neither package was going to move forward with > a binary named "node" Some proposed this, some agreed, others did not. In the just reported bug #671120 I wrote regarding this neither package should get the name part of the policy: | The common reading of the according section does neither match what | seems to be the original intention [1] nor my common sense. | | [1] http://lists.debian.org/<879142cjni@slip-61-16.ots.utexas.edu> > The proposal was made for a transition plan to be made then the nodejs > person quit talking/posting. Ian's proposal was as far as I understood it when reading it basically rolling a dice and I hope that I either misread it or that it was meant as a joke. If the node package needs to rename the binary it obviously needs a new name ;) Hamish suggested axnode once, the patch lying in the BTS uses ax25-node. Do you have any preference in case it is needed? Thanks for caring about this thread. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120501223105.gb14...@furrball.stateful.de
Re: Node.js and it's future in debian
* Jonathan Nieder [2012-05-01 12:57 -0500]: > Carsten Hey wrote: > > > I don't think that there ever will be a consensus in all those > > discussions without discussing in a reasonable way (which failed in the > > past multiple times). > > Note that a consensus does not imply everyone agreeing. I was talking about a consensus among the maintainers of the affected packages. Even if all but the maintainers of one of the affected packages would agree to a solution, there would be no way to implement this solution without asking the tech-ctte or (what would be not appropriate for this) a GR. > I am starting > to see a consensus already and would welcome well reasoned opinions > and clarifications that show where my understanding is lacking. > > By the way, separate from what happens to the "node" command are a few > other questions: > > - Can we come up with alternate names for both commands, so while >Debian users might be using the "node" command, Debian packages do >not need to? nodejs for node.js and ax25-node for the ham radio node. If ax25-node is not appropriate, then one of the debian-hams can suggest something more appropriate. >I think on the Node.js side this is basically a solved problem, I would consider a Linux distribution that uses /usr/bin/monty-python as binary for the python language to be utterly broken. Users of it would not be able to run any python script without adapting its shebang. Even making /usr/bin/python a symlink that can be changed between a game and the language would not make the situation any better, since users that do not want to change the shebang line would need to check if the symlink is set to the language on every box they want to run a python script on. node.js might not be that widespread in use as python, but shipping a node.js with /usr/bin/nodejs seems to be broken in a similar way as the above example. Anyway, if the nodejs maintainers would be happy with a hack that involves changing /usr/bin/node to /usr/bin/nodejs, then there is not much we could do about this as it's their package. > - Is the "node" package undermaintained? Should it be orphaned to >encourage active users to take on the burden of its maintenance >without worrying about stepping on people's toes? If it would be orphaned, then the problem could be solved easily by a QA-upload. It was maintained in a great way until the one that did the last upload retired from maintaining it in 2009. I'd assume that a FTBFS bug or a missing dependency would be solved by the remaining uploaders quickly (as it happened in 2005 once) and the packages does not require much attention in general. I don't think it is orphaned, but I also wouldn't consider it to be well maintained either. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120501192020.gd17...@furrball.stateful.de
Re: Node.js and it's future in debian
* Carsten Hey [2012-05-01 01:07 +0200]: > Only Hamish, who did not respond to this issue, uploaded > node once in 2005, I need to correct myself, Hamish replied once. In <20110208230458.ga23...@risingsoftware.com> he wrote: | I think renaming the node binary to axnode is reasonable and | consistent with this, but I don't think the nodejs program should be | using that name either. Pat replied earlier than I thought, but these earlier replies were indistinguishable from replies of other people that are not listed in the uploaders field (i.e., without priorly checking who is listed in it). The origin of what the policy suggests to do if there is no consensus is a mail from Guy Maor <879142cjni@slip-61-16.ots.utexas.edu>, in which he writes: | That's basically a stick to force developers to reach a consensus. Christian Schwarz uploaded this change later in this month. I don't think that there ever will be a consensus in all those discussions without discussing in a reasonable way (which failed in the past multiple times). Previously to this, asking the VP of Engineering for a decision was suggested in this thread. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120501160354.gz17...@furrball.stateful.de
Re: Node.js and it's future in debian
* Carl Fürstenberg [2012-04-28 03:31 +0200]: > There has been an log struggle between the nodejs package and the node > package, which is still unresolved (bug #611698 for example) And I > wonder now what the future should look like. In short I think that there is only one sane solution to this and that the way to reach this solution is to ask the tech-ctte for a decision. This is the second thread about this topic on -devel, the first one was in November 2011. In both threads and in some smaller ones, people basically claimed things like (incomplete list): * node is older and nodejs should have checked the binary name * first come first server * nodejs is used as node in the shebang line * my node is more widely used than yours (which node is meant depends on the year) * node is a daemon and there it does not matter what name it uses * one of them should use the binary name node * none should use the binary name node if there is no consensus * let the user decide via debconf * users from either group would complain if they need to use a name other than node * policy is wrong, packages should conflict * conflicts would be wrong Nowadays, the popcon stats for both packages strongly suggest that most of node's user are users that wanted to install node.js and did not remove the node package after noticing that it is not what they expected. Given that node is a rarely used daemon and that nodejs is a widely used language, I think that nodejs should get the binary name node; but due to the non-responsiveness of node's maintainers I think this might be a case where involving the tech-ctte would help. node's maintainers don't participate in such discussions in a reasonable and timely manner, for example the RC bug had no action for months despite the patch and nobody ever explained what exactly the problem of a changed binary name for a daemon would be (node can be used interactively, but it is not supposed to be used that way and those users that do would be able to set up an alias anyway). The first answer from one of the uploaders was sent nearly a year after nodesjs' maintainer asked about this issue on the maintainer's list (back then he didn't seem to notice that those who answered were unrelated to the node package). The subject of the -devel thread last year "Is anyone maintaining (the ham radio tool) node?" speaks for itself. I assume all of node's uploaders did great work on many ham related packages, but all that the two uploaders that replied to this issue during the last two years did related to the node package is that they also replied to the "Call for debian hamradio developers pool" from node's actual but now retired maintainer who then added them as uploaders. Only Hamish, who did not respond to this issue, uploaded node once in 2005, the others did never do any upload. The responses from the other two uploaders were essentially "please report a bug" (although this was already done) by one; and "... then no package should get the name" and in one mail "this patch needs to be tested by someone who runs node and nodejs" by the other. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120430230711.gb17...@furrball.stateful.de
Re: Definition of _boot_
* Vincent Bernat [2012-04-30 20:30 +0200]: > OoO En ce doux début de matinée du lundi 30 avril 2012, vers 08:15, > Svante Signell disait : > > >> I'm rather sure that he wants to define booting as part of what > >> currently is done in /etc/rcS.d. Configuring the network or mounting > >> non-essential remote file systems wouldn't be part of this definition. > >> > >> Then he would state that these early tasks do not need events at all, > >> and conclude that later tasks can be handled in event based userspace > >> tools, but that the initial process that invokes these event based tools > >> doesn't require events and thus can stay simple. > > > Nice summary, thanks. This is the whole idea behind defining boot... > > Some people get it, others don't. > > Since your boot definition is mostly the current initrd, you seem to > agree that the current init system could be replaced with something more > current like upstart and systemd. What you claim is not true. If the system is up that far as his boot definition would have implied, it would be easy for him to write a simple shell script to do the rest or to install file-rc. For the rest of us, it would be easier to work around upgrade problems like the ones udev's maintainer fixed for us for the last two releases. Looks like sending a thread's summary before the thread started does not end it ;) Unless someone plans to write yet another init replacement or to adapt an existent one, I think this discussion will not lead us to anything helpful. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120430191414.ga17...@furrball.stateful.de
Re: switching from exim to postfix
As I'm not involved in developing dma at all, neither upstream nor in Debian, I'm not the right one to discuss implementation details in depth with. * Russ Allbery [2012-04-29 17:32 -0700]: > Adam Borowski writes: > > On Sun, Apr 29, 2012 at 10:50:45PM +0200, Carsten Hey wrote: > > >> Looks like the DragonFly Mail Agent (dma), which already has been > >> mentioned in this thread, could become a decent default for Wheezy+1 > >> after some small changes. > >> > >> In a nutshell: it's able to deliver locally and remotely, has a queue, > >> supports TLS/SSL, does not listen on port 25 and instead of running as > >> daemon, it if run every 5 minutes via cron to flush the queue. > > > I hope you mean: to run retries (in which case every 5 minutes is an > > overkill). > > > Delaying every outgoing mail by 5 minutes doesn't sound like a good idea > > to me. > > ... incron ... You'd still need timed handling of queued mail for retries. There are two modes dma can run in, one is the deferred mode, which seems to be basically how you think dma always works. The other is the immediate mode that is default in Debian and upstream and as the name suggests it delivers immediately if possible and it forks for mails that can not be delivered immediately. The resulting processes then handle besides obvious other things the timed handling of queued mail for retries. The rest of this mail is likely not interesting for most of you since it only tries to answer the natural follow up question "Why does it need a cronjob then?" and explains why I don't think anymore that a switch to incron should be considered. Two reasons for running dma -q via cronjob in my own words but stolen from README.Debian are: * If the queue is not empty after reboot, dma -q needs to be run at least once to start delivering these mails. A @reboot cronjob or an init script would also to this job. * Delivery processes might die for various reasons, but the mails still need to be delivered in a timely manner. If dma would be the default MTA, then it should IMHO be as reliable as possible and even try to prevent user errors. If a user would unintentionally enables deferred mode (which is useful if you are behind a dial-up line) but would not set up dma -q to run periodically, then the mails would not be delivered without such a default cronjob. A comment that reminds users to adapt the cronjob if needed should be added to the config file. If dma -q is run every 5 minutes be default anyway, the option -bq does not make that much sense anymore; this can possibly be solved by implementing different ways of processing queued mails. All in all, enabling the cronjob by default, as it is already done in Debian, seems to be sane. > I think that was Carsten's point about switching to incron, which > would then do the right thing for new outgoing mail. This is a reasonable and logical assumption, but it is wrong ;) Actually the reason to mention incron was that I thought that running dma -q if triggered by inotify could be a bit cheaper than running it every five minutes. For a default MTA, the amount of systems that run it could make considering even minimal differences in efficiency worthwhile. The idea was to use incron to restart failed delivery processes, if this would be possible at all depends on details of dma and incron/inotify I'm not aware off. An additional reason to the explanation above not to use incron is that in rare cases dma might fail for example with ENOMEM whilst reading its configuration file before it is able to open any file in the spool dir, which would render running it by incron to be not 100% bullet proof anyway. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120430095818.ga6...@furrball.stateful.de
Re: Definition of _boot_
* Svante Signell [2012-04-29 21:51 +0200]: > In line with the recent discussion, lets aim at defining what _boot_ is: I'm rather sure that he wants to define booting as part of what currently is done in /etc/rcS.d. Configuring the network or mounting non-essential remote file systems wouldn't be part of this definition. Then he would state that these early tasks do not need events at all, and conclude that later tasks can be handled in event based userspace tools, but that the initial process that invokes these event based tools doesn't require events and thus can stay simple. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120429214803.gb23...@furrball.stateful.de
Re: switching from exim to postfix
* Joey Hess [2012-04-29 14:22 -0400]: > Joerg Jaspert wrote: > > It's insane to even think of switching one full featured MTA against > > another full featured one. It feels like "gosh, i dislike $onepiece, > > lets all move to $differentpiece", though both are bad as default. Looks like the DragonFly Mail Agent (dma), which already has been mentioned in this thread, could become a decent default for Wheezy+1 after some small changes. In a nutshell: it's able to deliver locally and remotely, has a queue, supports TLS/SSL, does not listen on port 25 and instead of running as daemon, it if run every 5 minutes via cron to flush the queue. Maybe it could be changed to use incron and not cron on Linux. It's README.Debian contains more verbose information. It currently lacks support for .forward files, ignores -bs, misses -F, ignores -om and the newaliases command exits with 1 if run without arguments. I'm nore sure if the latter two are problematic. > Yeah, Debian has certianly never done that before .. > (Remember smail? It's still mentioned in Policy even!) JFTR: According to [1] and [2], the reason to switch away from smail was that exim are easier to configure. [1] http://lists.debian.org/debian-devel/1998/11/msg00415.html [2] http://lists.debian.org/debian-devel/1998/11/msg00489.html > > If you really want to invest work, the time is much better spent in > > getting one of those tiny replacements a default. And then anyone who > > wants/needs a real one can change. Much more useful that way. > > That would be a fairly viable route. Although it slightly begs the > question of what task-mail-server would then pull in instead. If there will ever be a Debian user survey (again?), this question would be a good fit. At least GRML did user surveys in the past: http://grml.org/survey2011-results/ Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120429205045.ga23...@furrball.stateful.de
Re: Node.js and it's future in debian
* Carl Fürstenberg [2012-04-28 03:31 +0200] > The the hamradio package "node" shipping a binary called "node", and > as it's so old, the developers argue that the package must ship > a binary called "node" or breakage will occur. Upstream's INSTALL file contains: | Node is intended to be called from ax25d or inetd. It doesn't need | any command line arguments but there is one to support incoming | compressed connects. See the node(8) manual page. So the breakage is that people would need to update their config files? * Roger Leigh [2012-04-28 10:41 +0100]: > From a purely pragmatic POV, how many people are using both packages? I don't think that the answer is zero, but I also don't think that the answer is that far away from zero. node ships /usr/sbin/node and nodejs ships /usr/bin/node, so there is no file conflict from dpkg's point of view and if only one of both packages is installed, then things just work. Only for those cases where users install both packages, a special solution needs to be found. hamradio's node only accepts one option, -c, no other arguments. If nodejs is invoked with this option it responds with "Error: unrecognized flag -c" (but still enters its interactive mode). If nodejs' upstream agrees to never add this option, it is easy to detect which node is intended to be run unless node is invoked without any arguments. If used in a shebang line, there is always an argument that is not '-c'. nodesjs evaluates what it reads from stdin; if hamradio's node does not do anything with stdin (I'm not sure about this), the remaining cases where it is not clear which node should be run would be when it is invoked without any arguments and if test -p /dev/stdin is false. If the few users that install node and nodejs would be asked which one should be invoked if run without any arguments, both node binaries in their path could be diverted away and replaced with something similar to the shell snippet below (yes, I know that alternatives does not really fit here, that "[ -p /dev/stdin ]" might need to be removed and that a wrapper written in C might be more robust). #!/bin/sh if [ $# -eq 1 ] && [ "$1" = "-c" ]; then exec /usr/sbin/hamnode -c elif [ $# -ge 1 ] || [ -p /dev/stdin ]; then exec /usr/bin/jsnode "$@" else exec /etc/alternatives/node fi Since nodejs will be installed by way more people and the amount of questions should IMHO be kept low, I think that this magic should either be in the package node; or be in both packages in a way that avoids questions to be asked if only one package of the two packages is installed. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120428170919.ga30...@furrball.stateful.de
Re: Unofficial repositories on 'debian' domains
* Stefano Zacchiroli [2012-03-05 08:40 +0100]:
> On Sun, Mar 04, 2012 at 10:59:39PM +, Ben Hutchings wrote:
> While we are at it, I also think we should provide an index of
> *.debian.net entries on that splash page.
> http://wiki.debian.org/DebianNetDomains is just too prone to outdateness
> and incompleteness. The index can be automatically generated from LDAP
> and. IIRC a past chat with DSA, DSA is fine with that but is aware of
> privacy concerns that some of the registrant of *.debian.net entries
> might have. Personally, I don't think we should be worried about privacy
> concerns there. The debian.net is a Debian project resource and we
> should be ready to advertise all its entries, otherwise people should
> not register them in the first place.
In a non-public mail, Rhonda explained an argument against publishing
such automatically generated lists. A short summary is:
DSA uses ACLs for access control of information available via LDAP.
Circumventing this access control by publishing these lists would be
a violation of DMUP.
Considering the above argument, an explicit permission from DSA
(possibly alternatively from the DPL) might be needed to be able to
publish the generated list.
An other argument against publishing the list is that this information
used to be non-public. Publishing information that used to be
non-public without noticing people priorly to give them the chance to
remove the part they do not want to be published is not that nice. The
canonical way to reach all DDs is to send a mail to debian-devel-announce.
I think if we decide to publish a list of all .debian.net domains, such
a mail should be sent.
A related problem is that there is no general way to find out how to
reach someone being responsible for a specific .debian.net service. The
DD that originally registered the domain is not necessarily still
involved in providing the service and possibly might registered the
domain on behalf of someone who is not yet a DD. A way to solve the
first is to update the account linked to the domain if the original
registrant is not involved anymore; the second could be solved by
requiring the DD that registered it to act as proxy to the responsible
person (mentioning the real contact address on the services web site
would avoid the need to act as proxy in most cases).
A different approach to try to solve this reachability problem is to set
up an email forward from ${service}@dotnet.debian.org to the appropriate
email address.
Carsten
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120305233002.ga28...@furrball.stateful.de
Re: Multiarch file overlap summary and proposal
* David Kalnischkies [2012-02-17 17:20 +0100]: > Why would it be intuitive to add a specific value for the arch attribute with > apt-get install foo # arch |= native > but remove all values of the attribute with > apt-get remove foo# arch &= ~all-architectures > ? We had a similar discussion years ago. Package: foo Depends: a, b, c Conflicts: x, y, z To be able to install foo, you need to: * ensure that "a && b && c" is true. The command to do so is apt-get install a b c * ensure that "x || y || z" is false. The command to do so is (or rather "should in my opinion be") apt-get remove x y z To satisfy the dependency line, *all* packages in it need to be installed. To "satisfy" a conflicts field (that is, there is a conflict), *any* of the packages in it needs to be installed. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120217191404.gb29...@furrball.stateful.de
Re: Multiarch file overlap summary and proposal
* David Kalnischkies [2012-02-17 14:15 +0100]:
> You generously left out the paragraph describing how APT should
> detect that the package foo is in fact a library ...
My impression was that you think very library centric. All I wrote was
(in other words), that we should consider non-library packages as much
as library packages, and I did not write nor implied that libraries
should be handled in a different way.
> Is 'apt-get remove foo+' then going to install all foo's or just one?
"apt-get install g+++" is a weird syntax.
> The current implementation of always foo == foo:native doesn't fail
> your diagram, too, so what is this going to show us?
It depends on how one reads it, anyway, examples I consider to be
inconsistent are more helpful than a diagram without clear semantic.
# dpkg --print-architecture
amd64
# perl -00 -lne 'print if /^Package: (clang|tendra)$/m &&
/^Status: install ok installed$/m' /var/lib/dpkg/status \
| awk '/^Package:/ {printf "%s:", $2} /^Architecture:/ {print $2}'
tendra:i386
clang:i386
I was not able to find a command that shows this information.
# apt-cache policy tendra | sed -n 1p
tendra:i386:
# apt-cache policy clang | sed -n 1p
clang:
# apt-get remove tendra
The following packages will be REMOVED:
tendra:i386
# apt-get remove clang
Package clang is not installed, so not removed
The above shows that it seems to depend on the availability of
foo:native if apt-get remove foo removes foo:foreign.
# dpkg -l | awk '$2=="clang"{print}'
ii clang 3.0-5 Low-Level ...
# dpkg -S bin/clang
clang: /usr/bin/clang
clang: /usr/bin/clang++
# dpkg -r clang
dpkg: warning: there's no installed package matching clang
# apt-get remove clang
Package clang is not installed, so not removed
According to dpkg's command line interface, the file /usr/bin/clang is
in the package clang and dpkg -l shows it as installed, but it can not
be removed using this name, neither by apt nor by dpkg.
# dpkg -l | grep libzookeeper-st2
ii libzookeeper-st2:amd64 3.3.4+dfsg1-3 Single ...
ii libzookeeper-st2:i386 3.3.4+dfsg1-3 Single ...
Unlike the above dpkg -l output showing the foreign clang package,
libzookeeper-st2 is shown with the architecture appended.
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120217185319.ga29...@furrball.stateful.de
Re: Multiarch file overlap summary and proposal
* Russ Allbery [2012-02-16 14:55 -0800]: > Carsten Hey writes: > > There are still files that differ that do not need to be fixed, for > > example documentation that contains it's build date. > > Every file that differs has to be fixed in the current multi-arch plan. > Documentation that contains its build date is going to need to be split > out into a separate -docs package. I doubt that ftpmaster would be happy about -doc packages that contain just a few small man pages. > I'm fine with splitting documentation; that has far fewer problems than > splitting other types of files, since documentation isn't tightly coupled > at a level that breaks software. debianutils uses a special make target 'prebuild' in debian/rules to update build system related files and PO files before the actual source package is built. This basic idea also could be used to build problematic documentation files on the maintainers computer before he/she builds the package. The other targets would then install the prebuilt documentation into the package without the need to build it first. A proper dependency on debian/$prebuilt_doc could ensure that maintainers do not forget to run debian/rules prebuild. If maintainers choose to use such a target, suggesting a common name for it in the developers reference could be reasonable. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120217082256.ga19...@furrball.stateful.de
Re: Multiarch file overlap summary and proposal
* Russ Allbery [2012-02-16 10:43 -0800]: > * Users who want to co-install separate architectures will immediately > encounter a dpkg error saying that the files aren't consistent. This > means they won't be able to co-install the packages, but dpkg will > prevent any actual harm from happening. The user will then report a bug > and the maintainer will realize what happened and be able to find some > way to fix it. > > * Even better, we can automatically detect this error case by scanning the > archive for architecture pairs that have non-matching overlapping files > and deal with it proactively. There are still files that differ that do not need to be fixed, for example documentation that contains it's build date. One way to address this is to use a new dpkg control file (placed in /var/lib/dpkg/info) that lists files that dpkg considers to be equal even if they differ. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120216224340.gb8...@furrball.stateful.de
Re: Multiarch file overlap summary and proposal
* David Kalnischkies [2012-02-16 03:59 +0100]:
> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
> >>> it needs to find and remove foo:*
foo:all (or foo:any) instead of foo:* would save the need to quote it.
> > Actually, why would that be the behavior? Why would dpkg --purge foo not
> > just remove foo for all architectures for which it's installed, and
> > require that if you want to remove only a specific architecture you then
> > use the expanded syntax?
>
> We (as in APT team and dpkg team) had a lot of discussions about that,
> see for starters (there a properly more in between the 10 months…)
> [0] http://lists.debian.org/debian-dpkg/2011/01/msg00046.html
> [1] http://lists.debian.org/debian-dpkg/2011/12/msg5.html
>
> In short, i think the biggest counter is that it feels unintuitive to
> install a library (in native arch) with e.g. "apt-get install libfoo"
> while you have to be specific at removal to avoid nuking 'unrelated' packages
> with "apt-get remove libfoo".
I would expect this (especially if the package foo is not a library, but
I would also expect this for libraries):
* apt-get install foo tries to install foo:native if possible, if it is
not possible, it tries to install the package foo from an other
architecture but ask before proceeding (as if additional dependencies
are required to install a package).
* apt-get remove foo removes all installed foo packages (on all
architectures).
This summarises how apt without multi-arch handles this, the above would
make apt with multi-arch also behave so:
apt-get install foo
--->
foo is not installed foo is installed
apt-get remove foo
<---
> > Note that this obviously requires that a binNMU not be considered a
> > different version of the package for this purpose. But I think that too
> > makes sense. A binNMU *isn't* a full new version of the package; it's a
> > new build of the same version. We've historically been a bit sloppy about
> > this distinction, but I think it's a real distinction and a meaningful
> > one.
>
> Mhh. The current spec just forbids binNMU for M-A:same packages -
> the 'sync' happens on the exact binary version.
> Somewhere else in this multiarch-discussion was hinted that we could
> sync on the version in (optional) Source tag instead to allow binNMU.
> It's a bit too late (in my timezone) for me to do serious predictions on
> difficult-levels on changing this in APT but i guess its relatively easy.
> (the only problem i see is that i don't have ${source:Version} available
> currently in the version structure, but we haven't even tried pushing
> apt's abibreak to sid specifically as i feared "last-minute" changes…)
I'm not sure if you meant this with "Source tag", anyway, the 'Packages'
files miss the source version too, but this could be added as optional
field that would be used if it differs from the 'Version:' field.
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120216221059.ga8...@furrball.stateful.de
Re: Probable multiarch related problem in finding header file posix_types_32.h
* Steve Langasek [2012-02-14 09:29 -0800]: > Where we've run across similar problems with posix_types.h in the recent > past, it has indeed been due to the use of "gcc -I-". Drafts of the C89 and C11 standards read: | A preprocessing directive of the form | # include "q-char-sequence" new-line | causes ... If this search is not supported, or if the search fails, | the directive is reprocessed as if it read | # include new-line | with the identical contained sequence (...) from the original | directive. GCC's texinfo documentation (for version 4.4) of both options, -I- and -iquote, doesn't seem to contain anything that would contradict the above. > ultimately though I think this is a bug in linux-libc-dev for using > #include "" here. Or it is a bug in the preprocessor, i.e., gcc? Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120215230448.ga16...@furrball.stateful.de
Re: Summary: dpkg shared / reference counted files and version match
* Guillem Jover [2012-02-10 23:56 +0100]:
> * binNMUs for the same version might not be co-installable because doc
> generators, compressors, etc, might not always produce the same output.
>
> ... A possible fix, but only for the compressed files case might be to
> ship them uncompresesd, but that counters the desire to reduce wasted
> space.
An other fix is to reuse the compressed files from an existing binary
package (after verifying that the file's uncompressed content is the
same) as last resort solution. Such a tool could be used on buildds and
manually by maintainers if necessary, for example for binNMUs if we do
not solve the current gzip problem or if gzip's format will change.
> * binNMUs for the same version cannot be co-installed anyway as their
> changelogs differ.
Packages could ship /u/s/d/package/changelog:#ARCH#.{gz,Debian.gz}, and
in postinst create a symlink from the current changelog location to an
arch qualified one:
bn=/usr/share/doc/#PACKAGE#/changelog
ext=Debian.gz
[ -e $bn:#ARCH#.$ext ] || [ -L $bn:#ARCH#.$ext ] || ext=gz
[ -e $bn.$ext ] || [ -L $bn.$ext ] ||
ln -sn changelog:#ARCH#.$ext $bn.$ext 2>/dev/null || :
The prerm script would either remove or change the symlink if it points
to the package being removed.
Notes/Remarks :
* Instead of symlinks, diversions could be used, possibly in
combination with hardlinks if the files do not differ.
* Line 2 and 3 could be replaced by an assignment, given that there are
two variants of both scripts and debhelper includes the appropriate
one.
* The according prerm currently has 373 bytes, and used to have way
more before I switched to a more compact code.
* If 'changelog' and architecture would be separated by a period and
not by a colon, it would be impossible to distinguish between, for
example, changelog.amd64.gz and changelog.old.gz without knowing
a complete list of all possible architectures.
* test -ef (as shell builtin) is not allowed in maintainer scripts.
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120212013648.gb17...@furrball.stateful.de
Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)
* Aron Xu [2012-02-09 01:22 +0800]:
> Some packages come with data files that endianness matters, and many
> of them are large enough to split into a separate arch:all package if
> endianness were not something to care about. ...
Debian Policy, begin of section 5.6.8:
| Depending on context and the control file used, the Architecture field
| can include the following sets of values:
| * A unique single word identifying a Debian machine architecture as
|described in Architecture specification strings, Section 11.1.
| * An architecture wildcard identifying a set of Debian machine
|architectures, see Architecture wildcards, Section 11.1.1. any
|matches all Debian machine architectures and is the most frequently
|used.
| * all, which indicates an architecture-independent package.
| * source, which indicates a source package.
Possible addition to solve your problem:
* littleendian[1], which indicates a package that is installable on
all little endian architectures.
* bigendian[1], which indicates a package that is installable on
all big endian architectures.
The following paragraph could be (changes are marked in a wdiff like
format):
| In the main debian/control file in the source package, this field may
| contain the special value all, the special architecture wildcard{+s+}
| any{+ or endian (which matches littleendian and bigendian)+}, or
| a list of specific and wildcard architectures separated by spaces. If
| all{+, endian+} or any appears, that value must be the entire contents
| of the field. Most packages will use either all or any.
[1] The dash before endian to make it more readable is omitted to make
the resulting architecture wildcards (see Debian Policy, section
11.1.1) more consistent with the existing ones.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2012021216.ga17...@furrball.stateful.de
Re: Dependencies of metapackages
* Josselin Mouette [2011-09-01 09:52 +0200]: > I think we could solve a lot of those problems by treating metapackages > specially in APT. Ubuntu has a section "metapackages", introducing such a section in Debian could be the first step to treat metapackages specially. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110902165452.ga26...@furrball.stateful.de
Re: combined dependencies?
* Michael Tautschnig [2011-08-24 14:31 +0200]: > > Its not any header package: dkms needs the _appropriate_ header > > package matching the installed kernel package. If > > linux-image-2.6.39-1-amd64 is installed, then dkms needs > > linux-headers-2.6.39-1-amd64. If linux-image-3.0-1-amd64 is > > installed in parallel, then dkms needs linux-headers-3.0-1-amd64, > > too. > > > > Its just an example, anyway. > > Isn't all you want (with l-i-1 = linux-image-2.6.39-1-amd64, l-h-2 = > linux-headers-3.0-1-amd64, etc.) > > Depends: (l-i-1, l-h-1) | (l-i-2, l-h-2) | ... The above depends line does not ensure that "the _appropriate_ header package" is installed since an old image and an old header would satisfy the dependency. Given that I have linux-image-3.14 and linux-image-3.20 installed, but not dkms nor any header package, installing dkms would force me to install in one of the above cases _any_ header package matching an installed kernel and in the other one to install _all_ header packages matching an installed kernel. If linux-headers-3.14 wouldn't be available in Debian anymore, the originally proposed combined dependencies would force me to remove linux-image-3.14 if I install dkms. Do we really want to force users to remove old kernel images (which they would possibly like to keep as fallback) if they install dkms the first time? What you proposed does not lead to forced removals of old kernel images, but, as already mentioned, it does not ensure the appropriate header being installed. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110828132306.ga29...@furrball.stateful.de
Re: /usr/share/doc/ files and gzip/xz/no compression
* Andreas Barth [2011-08-15 23:59 +0200]: > * Lars Wirzenius (l...@liw.fi) [110815 23:27]: > > On Mon, Aug 15, 2011 at 11:04:51PM +0200, Carsten Hey wrote: > > > * Lars Wirzenius [2011-08-15 18:33 +0100]: > > > > raw gz xz > > > > 584163 134 file sizes (MiB) > > > >0421 450 savings compared to raw (MiB) > > > > -421 0 29 savings compared to current gz (MiB) > > > In other words, it's 130 MiB against xz's 134 MiB. I'll leave it to > > others to decide if it's a significatn difference. > > bzip2 is definitly a more conservative choice than xz. If it's > smaller, than it's superior to xz. bzip2 has a better compression on average for some filetypes, xz[1] has a better compression on average for others: gzip bzip2 xz bzip2+xz[3] text files[2] 94312922 73496587 77783076 73496587 other files 16577181 14609893 14275484 14275484 sum110890103 88106480 92058560 87772071 Among the "other files" are also a lot of text files, if we would compress Debian packages instead, xz would win presumably. Anyway, I don't think this difference of 4 MiB on a desktop system is significant. I would prefer to avoid bloating the set of pseudo essential packages without a good reason and I think users should be able to decompress all files in /u/s/d. There are plans to let dpkg depend on liblzma2 instead of xz and it already depends on libbz2-1.0. If dpkg's dependency on libbz2 is planned to be removed in future, I would prefer to let libbz2 vanish from the pseudo essential set and use xz also for /u/s/d, otherwise I would prefer using bzip2 over xz for /u/s/d. Carsten [1] I did not use -e nor -9, but the difference should not be that big on files in /usr/share/doc. [2] find ... -regex '.*\(changelog\|copyright\|README\|TODO\|NEWS\).*[.]gz' [3] bzip2 for text files and xz for other files. This is of course nothing we should consider doing. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110815230257.ga27...@furrball.stateful.de
Re: /usr/share/doc/ files and gzip/xz/no compression
* Lars Wirzenius [2011-08-15 18:33 +0100]: > raw gz xz > 584163 134 file sizes (MiB) >0421 450 savings compared to raw (MiB) > -421 0 29 savings compared to current gz (MiB) Years ago I compared sizes of compressed files in /usr/share/doc using different compression methods too, possibly restricting to specific file types (for example changelog and copyright). > I'm OK with allowing use of xz for compressing the files. IIRC bzip2 had a better compression. Compressing dpkg's changelog on stable seems confirm this: $ zcat /usr/share/doc/dpkg/changelog.gz | bzip2 | wc -c 145586 $ zcat /usr/share/doc/dpkg/changelog.gz | xz | wc -c 167844 Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110815210451.ga25...@furrball.stateful.de
Re: Introducing Build-Recommends / Build-Core-Depends?
* Andreas Barth [2011-08-15 13:46 +0200]: > * Carsten Hey (cars...@debian.org) [110815 13:36]: > > An optional "Build-Depends:" field per binary package as you described > > is essentially the same as the following, with the notable difference, > > that the below could appear as it is in the output of, i.e., apt-cache > > showsrc without requiring maintainers of all those packages to invent > > a new syntax just to enable users and developers to look up information. > > > > Build-Depends[foo-stage1]: debhelper > > Build-Depends[foo-stage2]: debhelper, libx11-dev > > Build-Depends: debhelper, libx11-dev, libgnome2-dev > > No, it's not. > > There is an really large difference: This here means the maintainer > needs to write down by hand what the path to build the package is. There seems to be a misunderstanding, caused by choosing an unfortunate example, here is an other one: Source: emacs23 Build-Depends: gnome, kde, ncurses-dev Build-Depends[emacs23-nox]: ncurses-dev If necessary, debhelper could ensure that the binary packages's dependencies are included in the Build-Depends line. apt-cache showsrc emacs23 currently displays something similar to: Package: emacs23 Binary: emacs, emacs23-lucid, emacs23-nox, emacs23, ... ... Build-Depends: gnome, kde, ncurses-dev ... If per-package build dependencies are added, it could look like this with my proposal: Package: emacs23 ... Build-Depends: gnome, kde, ncurses-dev Build-Depends[emacs23-nox]: ncurses-dev ... With your proposal it would either miss information, invent yet an other syntax, or use multiple fields per source package with the same name but a different semantic: Package: emacs23 ... Build-Depends: gnome, kde, ncurses-dev Build-Depends: ncurses-dev ... Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110815123553.gc14...@furrball.stateful.de
Re: Introducing Build-Recommends / Build-Core-Depends?
* Steve McIntyre [2011-08-15 11:12 +0100]: > Andreas Barth wrote: > >Generic options are usually better IMHO, but well - YMMV. > > Often, yes. But also often at extra cost. Where is the added benefit > here - i.e. what are the use cases? I'm 100% behind making the > bootstrap phase more simple, but I can't see many others... Backporting a subset of the binary packages in a source package is one, e.g., I might want to run the latest emacs23-nox on a server, but not emacs23. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110815114258.gb14...@furrball.stateful.de
Re: Introducing Build-Recommends / Build-Core-Depends?
* Andreas Barth [2011-08-13 13:28 +0200]: > Also, the binary packages in the debian/control template could have > Build-Depends specified which means that they should only be built if > those packages are actually installed ... An optional "Build-Depends:" field per binary package as you described is essentially the same as the following, with the notable difference, that the below could appear as it is in the output of, i.e., apt-cache showsrc without requiring maintainers of all those packages to invent a new syntax just to enable users and developers to look up information. Build-Depends[foo-stage1]: debhelper Build-Depends[foo-stage2]: debhelper, libx11-dev Build-Depends: debhelper, libx11-dev, libgnome2-dev > Building with core Dependencies only > > If doing an build of the core functionality only, norecommends is > added to the environment DEB_BUILD_OPTIONS. How do I build foo-stage1, but not foo-stage2? With a binary option like the above, it does not seem to be possible, unless dpkg-buildpackage decides based on the installed packages which packages it builds. Doing so might require using equivs if in early bootstrapping stages a part of the build dependencies is manually compiled instead of installed via dpkg, and it might waste time if dpkg-buildpackage decides to build a large binary package that is not needed yet. The most obvious ways to specify which packages should be build seem to be mybikeisred=[foo-stage1,...] added to the environment DEB_BUILD_OPTIONS or a new optional environment variable DEB_BUILD_PACKAGES which would contains a comma separated list of to be built packages and an additional make target binary-pkg-foo-stage1 in debian/rules. To prevent building packages needed for bootstrapping only by default, a new field in the source package's paragraph of the control file could be used, e.g., "NotBuiltByDefault: foo-stage1, foo-stage2". Not adding such a field to the binary package's paragraph instead has the same reason as described at the beginning of my mail. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110815113559.ga14...@furrball.stateful.de
Re: Conditional Recommends
* Eugene V. Lyubimkin [2011-05-22 18:08 +0300]: > On 2011-05-22 16:07, Carsten Hey wrote: > > 'Enhances:', 'Provides', 'Conflicts' and 'Breaks' also require extensive > > scanning in the package database. > > Conflicts and Breaks do not. So, yes, partly true. I personally don't > want one more reverse-field to handle; Two remain, good enough ;) > > Anyway, this subthread is all about reverse recommendations, even with > > negations you would need to scan the whole repository for implications > > in 'Recommends:' fields, or they would neither solve the tdep problem > > nor the original problem (see the end of this mail). > > I did not spot further statements about this in the end of your mail. The point I had in mind is that forward recommendations, i.e., 'Recommends:' require more effort to maintain than backward recommendations for tdeps and similar packages. Below mentioned is just one way to implement the package relationships for tdeps, IIRC somewhere in this thread the real plans to do so are mentioned. tdeps with backward recommendations: Package: hexahop Package: hexahop-l10n-$LANGUAGE Recommended-By: hexahop & translations-$LANGUAGE The above is all the would be needed, additional to either a real package translations-$LANGUAGE or a virtual package with this name provided by hexahop-l10n-$LANGUAGE. tdeps with forward recommendations: Package: hexahop Recommends: !translations-da | hexahop-l10n-da, !translations-de | hexahop-l10n-de, !translations-es | hexahop-l10n-es, ... tdeps with forward recommendations and indirection: Package: hexahop Recommends: hexahop-translations Package: hexahop-translations Recommends: !translations-da | hexahop-l10n-da, !translations-de | hexahop-l10n-de, !translations-es | hexahop-l10n-es, ... The third example with indirections would have advantages if one l10n package contains the translations for multiple packages (which seems to be planned). Additionally, tdeps could be some kind of leaf packages, as mentioned in http://lists.debian.org/debian-project/2011/03/msg00039.html or just depend on the according package they provide translations for. > So, no, this subthread is not about reverse recommendations, it's about > conditional recommendations. I don't need to rescan the whole repository > to satisfy '!A | B-plugin-A' given I scanned it once for Provides. If apt and cupt don't (which would be correct, on a second thought), installing translations for new languages would be all but easy for users, unless package managers provides a clever way to do this. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110523215906.gb22...@furrball.stateful.de
Re: Conditional Recommends
* David Kalnischkies [2011-05-23 16:31 +0200]: > On Sun, May 22, 2011 at 16:07, Carsten Hey wrote: > > * Conflicts, Breaks, ..., Enhances: > > - satisfied if any of the clauses is true > > Uhm, a Conflicts/Breaks is satisfied if all clauses are false. This misunderstanding is caused by the unclear definition of when a Conflicts/Breaks is "satisfied", it is (depending on the definition) either satisfied if a package can be installed, or if a package can not be installed. According to De Morgen's law, the following are equal: Given that no installed package conflicts with or breaks package X, … package X conflicting with "A, B , C" can be installed if all are false, otherwise it can not be installed. … package X conflicting with "A, B , C" can not be installed if any is true, otherwise it can be installed. > That way you could say Conflicts = ! Pre-Depends. > (regarding "…": Replaces doesn't fit to well in here…) > (Enhances are reverse-suggests so i really don't understand > why it is in the same enumeration as Conflicts/Breaks…) "Depends: A, B, C | D" is equivalent to "Depends: A & B & (C | D)", although the latter is not a valid syntax in Debian. The commas in 'Depends:' fields can be read as 'and'. "Conflicts: A, B, C" is equivalent to "Conflicts: A | B | C" and the commas in 'Conflicts:' fields can be read as 'or'. Alternatively, it could also be read as "Pre-Depends: !A & !B & !C" - which would be very similar to "a Conflicts/Breaks is satisfied if all clauses are false". "Enhances: A, B, C" is equivalent to "Enhances: A | B | C" (the package is suggested if A, B or C is installed). Given that the package with the 'Enhances:' control field is X, "Suggests: X" in packages A, B and C would do the same. 'Conflicts:' and 'Enhances:' both do somehow the opposite of 'Pre-Depends:' or 'Suggests:' and are both in DNF. 'Depends:' et al. are in CNF. Also being in DNF is the reason I put 'Enhances:' into the same enumeration as Conflicts/Breaks. > > If we allow logical 'and' in clauses of disjunctive fields and add > > a field similar to 'Enhances:', but for reverse recommendations instead, > > the above example could be written as: > > > > Package: A-plugin-B > > Depends: A, B > > Recommended-By: A & B > > Such a plugin 'Enhances: A' and maybe only 'Depends: B'. > A plugin like xul-ext-firegpg (removed & discontinued upstream) enhances > iceweasel and depends on gpg. Still, i don't think it would be a good > idea to add something like 'Recommended-By: iceweasel & gpg' > as this promotes this plugin nearly to priority (desktop-)standard… Using a field 'Depends-Alternatively:' instead of alternative dependencies via pipe symbols in the 'Depends:' field would be a less sane solution, e.g.: Package: foo Depends: libc6 (>= 2.3.4) Depends-Alternatively: debconf, cdebconf … instead of: Package: foo Depends: libc6 (>= 2.3.4), debconf | cdebconf The above would have been a very similar way to express things as the proposed 'Recommends-When:'. The main point of my mail was to propose a more consistent alternative to 'Recommends-When:'. I don't know the details why gnome needs this or what exactly is planned for tdeps and thus can't judge if 'Recommends-When:' or my alternative is a good idea at all. > If you want to your package manager (front-end) to suggest you to install > the plugin if you have A, B or A & B installed then please go ahead and > implement it in your front-end. This would be even more wrong than implementing DPkg::Pre-Invoke and DPkg::Post-Invoke in apt instead of dpkg. > It will be for example interesting in stable to stable+1 upgrades: > The dependency trees are already now very long and big, it doesn't > help in any way if we add even more subtrees and make them > conditional… (you want an example? udev effected kde: #610991) I needed to upgrade epiphany-browser (or alternatively remove packages I did not want to remove) to be able to upgrade to apt/squeeze because of some python-libraries. > Also, just imagine for a second we have such a field, then exactly is > your package manager supposed to install A-plugin-B? > Remember: New Recommends of a package are installed on a > package upgrade - and i will come back to you at the time i am forced > to implement logic to decide if A & B is compared to A & B & C a new > Recommended-By clau
Re: Conditional Recommends
* Goswin von Brederlow [2011-05-22 11:55 +0200]: > "Eugene V. Lyubimkin" writes: > > > On 2011-05-21 21:41, Ian Jackson wrote: > >> Simpler than this, and simpler than constructions involving negations > >> (which would be very troublesome for the resolution algorithms), would > >> be: > >> > >> Package: A-plugin-B > >> Depends: A, B > >> Recommended-When: A, B Our current package relationship fields can be grouped into: * Depends, Recommends, Suggests, ...: - satisfied if all clauses are true - (subset of) conjunctive normal form - single clauses are allowed to contain logical 'or's, logical 'and's are not allowed. * Conflicts, Breaks, ..., Enhances: - satisfied if any of the clauses is true - (subset of) disjunctive normal form - single clauses are not allowed to contain a logical 'or' nor a logical 'and' (there were some logical 'or's in Lenny, but they were pointless and wrong) If we allow logical 'and' in clauses of disjunctive fields and add a field similar to 'Enhances:', but for reverse recommendations instead, the above example could be written as: Package: A-plugin-B Depends: A, B Recommended-By: A & B > What does that mean? Is A-plugin-B recommended when A is installed or B > installed? Or only if A and B are installed? I assume the later. How > would I write recommended if (A & B) | (C & D)? Recommended-By: A & B, C & D This also would save the need to possibly add the field 'Suggested-When:' and a reverse recommendation field similar to 'Enhances' in future. To prevent problems with partial upgrades, a logical 'and' should only be allowed in fields that do not exist in Squeeze. After Wheezy, they could be allowed in 'Enhances:' too and if there are according use cases, maybe even in Conflicts or Breaks. > > Putting my 'developer of unpopular package manager' on: no, no, pretty > > please, no reverse-Recommends. Firstly, one doesn't want to scan all > > package database to find all Recommends for the particular package, 'Enhances:', 'Provides', 'Conflicts' and 'Breaks' also require extensive scanning in the package database. Anyway, this subthread is all about reverse recommendations, even with negations you would need to scan the whole repository for implications in 'Recommends:' fields, or they would neither solve the tdep problem nor the original problem (see the end of this mail). > > and secondly, this is easily abusable by third-package maintainers > > and even packages from completely different, non-Debian > > repositories: > > > > Package: some-package > > Depends: gnome > > Recommended-When: gnome Third-party repositories have root access on your system, see Google's (past?) packages for things that could be done. Chrome does not abuse it but only fiddles in your sources.list and crontab because they want to ensure that you don't browse the internet with a browser full of security holes (whether this is a good way to do this does not seem to belong to this thread). I think all this is a different problem that should be solved in a different way, for example by a way to tell apt to ask the user before a new package from a third party is installed or by a tools similar to NetBSD's systrace that could be used to restrict what third party packages are allowed to do. > > And, still wearing the hat, negations are fairly easy to implement. If > > we ever go for implementing conditional dependencies, negations are > > great and powerful idea, I'd vote for them. I agree that negations are fairly easy to implement, given that only a subset of all possible things doable with negations (e.g., my implication example) are allowed and if you find a sane algorithm. Finding such sane algorithms is not that easy, at least not for all of us and especially not if you don't spend the necessary amount of time on thinking about it. > Maybe this would be better? > > Package: A > Recommends-If: B > C, D & E > F > > If B is installed then recommend C. If D and E are installed then > recommend F. This would _not_ be a reverse recommendation. One problem with forward recommendations is that adding new translations for a package would require adapting this package instead of only the translation packages. I don't think we could handle this in a sane way if we get tdeps for complete desktop environments (I'm not sure if this is planned). Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110522140717.ga25...@furrball.stateful.de
Re: Conditional Recommends
* Josselin Mouette [2011-05-21 13:24 +0200]:
> Therefore, I’m wondering whether it would be possible to extend the
> syntax of Recommends to allow for conditional dependencies. For example,
> in this case:
> Package: A
> Recommends: A-plugin-B {B}
The following would be more general:
Package: A
Recommends: !B | A-plugin-B
If we have had this syntax a lot earlier, for example "Build-Conflicts:
X" could have been written as "Build-Depends: !X". But we already
invented all those fields and the number of additional use cases for
exclamation marks as negation in package relationship fields seems to be
rather limited.
With above exclamation mark syntax, we could also express "weak
conflicts", e.g.:
Package: X
Recommends: !Y
Apt would remove Y by default if X gets installed, but users could
overwrite this.
Is there any need for such a weak conflict, e.g., to get rid of gcc-4.4
if gcc-4.5 gets installed? Apt's autoremove feature presumably already
handles most of these cases.
If we add conditional recommends and there is a need for weak conflicts,
I think we should choose a syntax that allows us to express both.
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110521155628.ga4...@furrball.stateful.de
Re: A concrete proposal for rolling implementation
* Pierre Habouzit [2011-05-05 07:46 +0200]: > On Wed, May 04, 2011 at 10:48:46PM +0200, Carsten Hey wrote: > > If more new upstream versions are uploaded to unstable (because they are > > targeted at rolling), it raises the number of RC bugs needing to migrate > > to testing through t-p-u. How would you ensure that they get enough > > testing before entering testing? > > That's the point, you don't target rolling, your goal is still to make > stuff migrate into testing, rolling is just the extra few packages > testing needs to fix the most important breakages that happen (e.g. your > PAM example, or large migrations where dependencies across libraries are > too loose and break testing, Joss said it happens to gnome quite a lot > e.g.). So rolling would principally also be frozen during testing's freeze, this is not what the name seems to imply. Unlike variants where rolling would really roll, this one does not require an additional pseudo-suite in Debian [1] and could be implemented on rolling.debian.net without convincing the release team and ftpmaster first. Regards Carsten [1] experimental would even with a way for maintainers to add a hint to their packages to let them migrate from experimental to rolling be the wrong one because of its low pinning. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110505174845.ga15...@furrball.stateful.de
Re: A concrete proposal for rolling implementation
* Pierre Habouzit [2011-05-04 22:23 +0200]: > On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: > > Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : > > > While I like the idea in general, I think that it should also be > > > possible to upload packages directly to rolling (through > > > rolling-proposed-updates). It will be useful in cases where neither the > > > package in testing, not the package in unstable, can be used to fix a > > > problem in rolling. > > > > Adding this possibility is opening Pandora’s box. Once you allow this, > > people start using packages that are neither in unstable nor in testing, > > and they don’t help us working on our packages at all. This also adds an > > extra burden on maintainers who want to use this feature. > > > > Could you please give a concrete example of where this would be needed? > > I think all existing cases should be covered by uploading directly to > > either t-p-u or unstable. > > Agreed, the entry point for rolling is clearly just unstable + a force > hint. Why would you need to upload something to rolling that you > couldn't make enter through unstable? If more new upstream versions are uploaded to unstable (because they are targeted at rolling), it raises the number of RC bugs needing to migrate to testing through t-p-u. How would you ensure that they get enough testing before entering testing? Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504204846.ga27...@furrball.stateful.de
Re: Bits from the Release Team - Kicking off Wheezy
* Lucas Nussbaum [2011-05-02 09:20 +0200]: > On 02/05/11 at 08:19 +0200, Pierre Habouzit wrote: > > Also note that testing as is has not enough security support, and > > read Carsten very good example of the PAM issues. How would CUT or > > rolling address those? > > The PAM issue outlines how splitting the users and developers between > two branches (unstable and testing post-freeze in the PAM case) causes > problems. In my opinion it outlines how migration through barely used suites (e.g., *-updates) significantly raises the number of buggy packages entering a frozen testing. The need to use those suites is mostly caused by uploading new upstream versions to unstable even though they will never reach the suite that currently is testing. > [C] we could compromise. We could freeze rolling for 3 months, so that > most of the stabilization work occurs with a single active branch, > and then, for the final release preparation, fork 'frozen' off > 'rolling', and unfreeze 'rolling'. The mentioned PAM issue happened four months after freeze. Decreasing the chances to catch critical bugs before they enter a frozen testing does not seem to be the best idea, especially if it is done shortly before we plan to release. It would be great if we would find a clever way to be able to release three months after freeze. If we don't find a way to do so, we could: * Add a non-selfcontained suite to upload non-experimental packages not targeted at testing to. This would lower the number of packages needing to go through testing-proposed-updates during freeze and could also serve as entry point for rolling. * Set up a dak instance for rolling and rolling-proposed-updates on rolling.debian.net, announce it and see if it works. * If it works, make rolling official. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502135115.ga22...@furrball.stateful.de
Re: Bits from the Release Team - Kicking off Wheezy
* Pierre Habouzit [2011-05-02 08:08 +0200]: > On Mon, May 02, 2011 at 01:56:14AM +0200, Carsten Hey wrote: > > * Pierre Habouzit [2011-05-01 23:17 +0200]: > > > The problem is, you need to entry points, one for testing as we know it, > > > one for rolling. > > > > Actually, we need two entry points each, a default one and an > > exceptional one. The latter ideally requires a special permission from > > a release team before an upload. For testing these are unstable and > > testing-proposed-updates. > > Urgh. Sounds a lot. 1st phase: - add unstable-proposed-updates 2nd phase: - create symlink rolling, pointing to testing - create symlink rolling-proposed-updates, pointing to testing-proposed updates 3rd phase: - freeze testing - make rolling and rolling-proposed-updates real suites If rolling is supposed to be a subset of testing, making rolling and rolling-proposed-updates real suites would need to happen earlier. This completely ignores what seems to be the original motivation for CUT. Maybe there is a different solution to provide what d-i alpha and beta releases need or reduce what they need. > > > If you use t-p-u for testing and unstable for rolling, or unstable for > > > testing and rolling-updates for rolling is just bikeshedding. The result > > > is some of the users will use unstable and help testing, the other sort > > > will run rolling-updates or rolling. > > > > > > So basically you split our users in two non overlapping sets, meaning > > > that you divide coverage and tests. > > > > The result of this bikeshedding has an influence on how big these sets > > are. > > I agree, the original sizes, I expect them to converge more or less to > the same end result, which is what is important on the long term. Many people just choose what's default. d-i installing testing instead of rolling by default would raise the number of the testing set. Requiring users of unstable + -updates to add -updates manually to the sources.list would in my opinion decrease this set of people. > > > I'm interested about *why* they want it, not the mere fact that they > > > do. Because when you know why they want it, maybe there will be better > > > answers that don't make releasing even more brittle and burn even more > > > people out. > > > > I guess it's mainly about new upstream versions (firefox, chromium, > > gnome and so on) they read in the news about, saw on other computers or > > really contain features useful for the users. > > > > Moving backports.org to backports.debian.org and enabling automatic > > upgrades by default are steps in the right direction to address this > > (except for desktop environments). backports.debian.org does not fit here, it makes stable more attractive for users that would otherwise run testing. Making testing more attractive for users that would otherwise run rolling could be done with "semi-official PPAs". Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110502130302.gr5...@furrball.stateful.de
Re: Bits from the Release Team - Kicking off Wheezy
* Pierre Habouzit [2011-05-01 23:17 +0200]: > On Sun, May 01, 2011 at 11:07:48PM +0200, Raphael Hertzog wrote: > > On Sun, 01 May 2011, Carsten Hey wrote: > > > > Testing, OTOH, is really unique in that respect, with its mixture of > > > > fresh software and quarantine period. > > > > > > A 'frozen' requiring most updates to go through *-proposed-updates would > > > make this quarantine period a lot less useful, and it would make > > > circumstances like the one described above a lot more probable. > > > > > > One cause that testing-proposed-updates is not more widely used is that > > > there is no good non-altruistic reason for a user to do so. More > > > up-to-date packages are available in unstable and more tested packages > > > are available in testing. > > > > There's a good reason to use testing-proposed-updates during freeze, it > > fixes security and release critical bugs that are present in testing! I should have highlighted the word "most". With the present scheme, updates to testing that need to go through t-p-u are exceptions. > > So if we tell users to use this repository, we're going to have > > some users (I upgrade my servers to testing during the freeze and I > > would enable it if it was generally advised for beta-testers). The libpam-mount example was not a 100% fit because it went through testing-security and not through t-p-a. The segfaulting package migrated to testing on the 28th of November 2008. Just five months earlier the "Testing Security team" announced[1] on d-d-a that they provide nearly full security support (the kernel was missing at this time). I doubt that generally advising to add t-p-a would significantly work out better than the testing-security announcement. [1] http://lists.debian.org/debian-devel-announce/2008/06/msg6.html > > But yes there might be some unrelated regressions from time to time. > > There's a reason why it's not labeled "stable" yet. Not being able to login is more than just a unrelated regression. Quote from #507199: | for users with encrypted volumes there is NO LOGIN POSSIBLE! it | renders my system unusable. without the crypted volumes, there is no | need to login at all... ( now i am glad that root does not have any | encrypted volumes! ) | | login is only possible, if all crypted volumes for the user are | commented out. With sudo instead of a "real" root account he would have needed to start a rescue system to be able to login again. > The problem is, you need to entry points, one for testing as we know it, > one for rolling. Actually, we need two entry points each, a default one and an exceptional one. The latter ideally requires a special permission from a release team before an upload. For testing these are unstable and testing-proposed-updates. > If you use t-p-u for testing and unstable for rolling, or unstable for > testing and rolling-updates for rolling is just bikeshedding. The result > is some of the users will use unstable and help testing, the other sort > will run rolling-updates or rolling. > > So basically you split our users in two non overlapping sets, meaning > that you divide coverage and tests. The result of this bikeshedding has an influence on how big these sets are. > How come is that in the distribution interest?! I think it's not, > I think it's resource squandering. I'm undecided if rolling in general is a good idea, but I think unstable-proposed-updates (the name does not matter, but the concept) would be a good thing, with or without rolling. This possible non-selfcontaining suite just happens to fit rather good into the rolling concept. I also think using t-p-u per default to feed testing would significantly lower the quality of a frozen testing (with an other color and thus different sized sets, it should in my opinion work though). > I'm interested about *why* they want it, not the mere fact that they > do. Because when you know why they want it, maybe there will be better > answers that don't make releasing even more brittle and burn even more > people out. I guess it's mainly about new upstream versions (firefox, chromium, gnome and so on) they read in the news about, saw on other computers or really contain features useful for the users. Moving backports.org to backports.debian.org and enabling automatic upgrades by default are steps in the right direction to address this (except for desktop environments). Supporting or even recommending to use all packages from b.d.o to make it feel like a rolling release would be nearly the opposite of how it is intended to be used now and I don't think it would make those users really more happy. So all in all, the scheme used
Re: Bits from the Release Team - Kicking off Wheezy
* Stefano Zacchiroli [2011-05-01 15:43 +0200]: > On Sun, May 01, 2011 at 02:06:19AM +0200, Pierre Habouzit wrote: > > I think that we should not do any trade off on the quality of > > rolling/testing/the-antechamber-of-stable, but instead raise the quality > > of unstable so that (which isn't *that* bad, unstable is rarely badly > > broken, and I know lots of "stable" releases of linux distributions that > > are in worse state than the average of unstable on the same set of > > packages…): > > YMMV, but I don't think the problem in using unstable directly is of > average quality, but rather the fact that you've little shields against > temporary yet severe breakages. Testing also has just little protection against severe breakage if it is frozen and updates need to go through rarely used suites. An example illustrates this quite well: When Lenny was frozen, a new upstream version of libpam-mount uploaded to sid. A fix for a release critical bug in libpam-mount/testing could thus not migrate through unstable and the maintainer uploaded it together with a security related fix to testing-security. The new package introduced a new bug, it segfaulted when logging in. This bug was not reported in the four days the package was in testing-security. After migration to testing, four according bugs were filed, two of them even within ten hours. I've put related dates, message-id's and bug numbers at the end of this mail[1]. > Testing, OTOH, is really unique in that respect, with its mixture of > fresh software and quarantine period. A 'frozen' requiring most updates to go through *-proposed-updates would make this quarantine period a lot less useful, and it would make circumstances like the one described above a lot more probable. One cause that testing-proposed-updates is not more widely used is that there is no good non-altruistic reason for a user to do so. More up-to-date packages are available in unstable and more tested packages are available in testing. Partly giving up the protection of the quarantine period just to get some packages a few days earlier seems to be a bad deal. > Out of all this discussion, the challenge that interests me is whether > testing (or something new, similar to it) can be targeted at final > users without having significant differences in its lifetime depending > on the release cycle of Debian stable. As many posts have shown, the > difficulty lies in how (and if) we can do that without harming the > stable release process itself. To avoid harming the stable release process, packages should to be tested by many users before they enter testing. The most used suite containing packages newer than testing is unstable. I think the migration of unstable to testing should stay as it is now, whether or not testing is frozen. If we want to add a new never-freezing suite 'rolling' targeted at final users, we should find a way to test packages in a sufficing way before they enter rolling. These packages would be newer than those in rolling or unstable, but adding a full suite above both does not seem to be reasonable. An non-selfcontained suite (like *-updates and experimental) between unstable and experimental could solve this. Unlike t-p-u, there would be a reason for users to opt-in to use this suite, since it would contains the latest non-experimental packages. The need to explicitly opt-in would help to ensure that pure unstable is sufficiently tested. Such a suite should be pinned to 500 by default to encourage using all packages from it rather than just picking specific packages, it should also only contain packages that would be uploaded to unstable if testing would not be frozen (both in contrast to experimental). After release, packages in it could migrate to unstable, either all at once or using a clever algorithm. In the following table, I only choose 'sid-updates' as name because it is short: - | not frozen |frozen - | sid| sid suites:| rolling| rolling | testing (equal to rolling) | testing (frozen) | stable | stable - | sid => testing/rolling | sid => testing migration: | no migration from sid-updates | sid-updates => rolling | t-p-u/r-p-u => testing/rolling | t-p-u => testing || r-p-u => rolling - In comparision to Raphael's proposal, the above would weaken the stability of rolling during the freeze a bit, but it would strengthen testing's stability. Maintainers would only need to support an additional release if they upload pac
Re: limits for package name and version (MBF alert: ... .deb filenames)
* Philipp Kern [2011-04-24 10:23 +]: > (OTOH it needs to be greater than +squeeze then, so +debXY won't do.) It needs to be greater than "+squeeze", smaller than "." and must not contain "-". /usr/bin/ascii prints: |Dec Hex | 43 2B + | 44 2C , | 45 2D - | 46 2E . ",debXY" would do, but would require a policy change and possibly changes in various tools. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110424120700.ga17...@furrball.stateful.de
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
* Luk Claes [2011-04-06 07:20 +0200]: > On 04/06/2011 01:55 AM, Carsten Hey wrote: > > Guaranteeing that /bin/sh exists and is functional during debootstrap, > > even before any maintainer script has been run, could be archived if > > every system shell would provide /bin/sh pointing to itself. To avoid > > file conflicts, all but the one whose preinst is run first (finding > > a clever way to detect this shouldn't be that hard) could divert their > > /bin/sh to /bin/sh.$SHELL. When update-shell (or whatever it's name > > would be) finally takes over managing /bin/sh, it could divert the > > remaining /bin/sh away and replace it with a symlink not known to the > > packaging system. > > That unfortunately does not work as diversions are only meant to be used > when 2 packages provide the same file. Actually, this impossible use of dpkg-divert was intended to be a way to work around the missing (or unwanted?) hook support in deboostrap and cdebootstrap. Packages in base could use these hooks to set up a part of what is currently done in /usr/share/debootstrap/scripts/. Without such hooks, adding /bin/sh could still be done in debootstrap and cdebootstrap. > One of the problems being what to do when you remove one of the shells > (for instance the one providing /bin/sh)... ksh's prerm script would call "update-shell remove /bin/ksh93". If /bin/sh would point to ksh93, update-shell would change /bin/sh to point to the registered system-shell with the highest priority. System shells would (de)register themselves by calling add-system-shell in postinst and remove-system-shell in prerm. 'system-shell' would also be a virtual package provided by bash, dash and so on. Although I don't think this would be a problem, using /bin/$SHELL in the shebang of postinst and prerm could prevent possible problems if /bin/sh changes whilst these scripts are running. * Simon McVittie [2011-04-06 11:22 +0100]: > > Passing a shell to it that is not included in /etc/shells could lead > > to failing of this tool, unless --force is used. > > Not everything in /etc/shells is POSIXy enough to be /bin/sh. This was not meat as whitelist but as "inverse blacklist" (everything not in it is most probable not a adequate /bin/sh). Anyway, this was a bad idea. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110407000526.ga27...@furrball.stateful.de
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
* Luk Claes [2011-04-05 23:11 +0200]: > On 04/05/2011 11:05 PM, Jonathan Nieder wrote: > > Carsten Hey wrote: > >> * Steve Langasek [2011-04-04 19:37 -0700]: > >>> On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote: > >>>> * Find a sane solution for managing /bin/sh. Currently diversions are > >>>>used, which looks like the wrong tool for this job to me. There are > >>>>also some related bugs with a high severity. > > > > The correct way to manage /bin/sh is as a configuration file. Of course it is. > > * dash would stop shipping /bin/sh in its data.tar > > * bash would stop shipping /bin/sh in its data.tar How would debootstrap be able to run the preinst scripts without a working /bin/sh, unless it runs bash's binary one first? > > * an essential package (doesn't matter which --- maybe debianutils) > >should take care of allowing other shells to influence where > >/bin/sh points. update-alternatives is (among other things) because of the indirection it uses the wrong tool, but a part of it fits rather good. Such a tool would need to support priorities to select per default dash as /bin/sh, if dash is not installed it would select bash and if both are missing it would select an other shell. It would also need to assure that whilst it is running /bin/sh is always functional. Passing a shell to it that is not included in /etc/shells could lead to failing of this tool, unless --force is used. > Well, that will only happen when it's cristal clear that it's guaranteed > that /bin/sh exists and is functional at all times in such a scenario. Guaranteeing that /bin/sh exists and is functional during debootstrap, even before any maintainer script has been run, could be archived if every system shell would provide /bin/sh pointing to itself. To avoid file conflicts, all but the one whose preinst is run first (finding a clever way to detect this shouldn't be that hard) could divert their /bin/sh to /bin/sh.$SHELL. When update-shell (or whatever it's name would be) finally takes over managing /bin/sh, it could divert the remaining /bin/sh away and replace it with a symlink not known to the packaging system. Running update-shells in postinst and prerm (and never in the other two) would additionally be required to ensure that /bin/sh is always functional. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405235520.ga5...@furrball.stateful.de
Re: Moving bash from essential/required to important?
* Steve Langasek [2011-04-04 19:37 -0700]: > On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote: > > Before bash or dash could be made non-essential in a clean way, there > > are IMHO various things not mentioned up to now in this thread to fix: > > > * Fix #428189, either by adapting the policy to reality or vice versa > >(depending on the maintainers decision) as prerequisite to fix the > >next point without breaking things afterwards. > > This doesn't appear to be relevant to moving bash out of Essential. dash, > which would still be Essential (no one is proposing removing /bin/sh from > Essential!), also has printf as a shell builtin. > > It would be good to resolve this bug in its own right, but it appears to be > orthogonal to whether bash is Essential. This is only relevant because the next point is in my opinion relevant and fixing the next one might lead the next best maintainer of a policy complying shell to enable this shell to become /bin/sh. If there is no correctly documented consensus (in the policy) about what a shell needs to provide to let scripts rely on printf (and theoretically also [ and test) being available, this could lead to non-bootable systems. > > * Find a sane solution for managing /bin/sh. Currently diversions are > >used, which looks like the wrong tool for this job to me. There are > >also some related bugs with a high severity. > > Also seems to be orthogonal. I agree that this seems to be orthogonal at first, and even second, sight. We are using different hacks to manage /bin/sh since about five years. Making things even more hackish or complicated, e.g. by not being able to rely on dash or bash to be installed and/or moving /bin/sh around, would increase the number of corner cases to be caught and thus make implementing a clean solution even more hard. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405101233.gc10...@furrball.stateful.de
Re: Moving bash from essential/required to important?
* Guillem Jover [2011-04-05 06:19 +0200]: > On Tue, 2011-04-05 at 01:08:19 +0100, Ben Hutchings wrote: > > This appears to open up any accounts that have been deliberately > > disabled by setting their shell to a nonexistent path. I know that's a > > dumb way to disable an account, but that doesn't make this any less of a > > security hole. > > > > How about checking for the configured shell in /etc/shells before > > enabling the fallback? > > Ah good catch! Done with the attached patch. mksh.prerm contains: remove|upgrade|deconfigure) update-alternatives --remove ksh /bin/mksh update-alternatives --remove ksh /bin/mksh-static remove-shell /bin/mksh remove-shell /bin/mksh-static bash.postrm contains: remove|purge|disappear) if which remove-shell >/dev/null && [ -f /etc/shells ]; then remove-shell /bin/bash remove-shell /bin/rbash fi ... so they are missing from /etc/shells after they have been removed. Alternatives include a hardcoded list instead of relying on /etc/shells or an additional file that contains all shells that were ever part of /etc/shells. prerm could also fail it the shell is set as root's (or any, otherwise setups using sudo instead of root might break) login shell. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405090235.gb10...@furrball.stateful.de
Re: Moving bash from essential/required to important?
Before bash or dash could be made non-essential in a clean way, there are IMHO various things not mentioned up to now in this thread to fix: * Fix #428189, either by adapting the policy to reality or vice versa (depending on the maintainers decision) as prerequisite to fix the next point without breaking things afterwards. * Find a sane solution for managing /bin/sh. Currently diversions are used, which looks like the wrong tool for this job to me. There are also some related bugs with a high severity. * Make dash conform to POSIX. dash/sid is not detected as being a POSIX shell by autotools, which leads to lines like #!@POSIX_SHELL@ to become #!/bin/bash and thus introduces useless dependencies on bash. * Lars Wirzenius [2011-04-04 20:32 +0100]: > On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: > > Regarding the root shell issue, I wouldn't have an issue with it > > being /bin/sh. The admin is always free to chsh it to the shell > > of their choice. > > We could even have d-i set the root shell to bash if it installs bash. > Or have bash do it always, even, if root's shell is /bin/sh. The login approach mentioned in this thread is in my opinion way more clean than fiddling with /etc/passwd. > > However, there have got to be hundreds of packages using bash > > without a dependency. Do we have any information on the > > affected packages (i.e. all those with a #!/bin/bash shebang in any > > provided executable scripts)? > > I happened to have access to a idle-ish fastish machine with a fresh-ish > Debian mirror, so I wrote a script to unpack all binaries (for sid/main > amd64), and then another script to grep for bash scripts (actually a > pair of scripts). With these scripts, I got a list of files that start > with #!/bin/bash. There are 1783 files in the list, in 543 packages. gzip_1.3.12-9_amd64.deb contains files in /bin/ starting with #!/bin/bash, maybe your script skips /bin/? The post installation script of libssl1.0.0.0 also contains a bash shebang line missed by your script. > Changing 543 packages to add a bash dependency does sound like a lot, > but it should be doable. > > * We can add a lintian warning, which helps catch such things in > the future. This would also require an exception to the "don't depend on essential" warning. > * We can perhaps change debhelper to automatically add the > dependency, if it is missing. Since most packages use debhelper, > this might transition most of the packages automatically. Ack. > * Or we might do a more traditional transition, with an MBF now, > and a targeted NMU campaign in six months, for any packages that > still remain. This sounds more like a possible release goal to me and not like something that needs to be fixed using NMUs in a few months. > I think this would be a nice thing to do, especially from the point of > view of embedded systems, and other systems with no interactive use, but > limited resources. I agree about the usefulness for embedded systems and think that (if there is some work done in this direction) the efforts should be done with them in mind. After all, deciding things that can't be done because of others blocking it is not the best idea. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011040536.ga10...@furrball.stateful.de
Re: time based freezes
The release team did again a great job the past release cycle and managed to release again a version Debian can be proud of :) There were of course things that could be done even better next time, but handling such a enormous task without such issues seems to be impossible. One thing that the release team already is improving is communication, for example, they did ask for feedback and welcomed comments in their mail to debian-devel-announce. One example of less outstanding communication that happened during the past freeze is that squeeze-updates has been announced without any prior discussion. Important aspects of proper communication include comprehensible justification of decisions and also predictability. As part of an explanation they once wrote "DebConf should definitely not fall into a freeze and that we should leave time after DebConf to ..." in an announcement. A year later they did the opposite and froze at the end of DebConf. Other reasons that were considered internally like synchronisation with other distributions were missing in this first mentioned announcement. The other thing that has potential to be improved is the freezing. The relevant part of freeze history is in my opinion: * There were two mails from the release team regarding uploads on d-d-a in the week before Lenny was frozen. * Contrary to what was communicated earlier, Squeeze was frozen weeks before most people expected it and before the announced Perl transition has happened. If the release team would skip those "we freeze next week" mails, there wouldn't be such a flood of uploads just before the freeze. If they would additionally stick with what they announce, nobody would complain that a freeze would have happened unexpected. * Stefano Zacchiroli [2011-04-03 18:15 +0200]: > On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote: > > Time based freezes > > -- > Road maps > - > > I believe we need time based freezes. Even more radically, I believe we > need to know the freeze date as soon as possible, e.g. no later than a > couple of weeks after the preceding release. (Obviously, transitioning > to time based freezes warrant exceptions to the rule.) I believe we need to know a vague time frame for freezing instead. With your proposal the release team might announce: We released on the 7th of February 2011 and freeze Wheezy one and a half year later on the 7th of October 2012. With mine they could announce: We released in February 2011 and we want about one and a half year between a releases and the following freeze, so we freeze in fall 2012. > My rationale for the above is simple: *road maps*. Each team and > individual developer should be able to define their own road maps very > early in a release cycle. Doing so will help teams in planning and > splitting work. Both would address the roadmap issue. > I believe it will also help maintainers in negotiating release dates > with upstreams which are sensible to distribution needs. Deciding whether this would be a good thing could be highly controversial. > Strict date > --- > > The difficult part in moving to such a scheme is that the freeze date > must be strict. We are in the good position to have a very experienced release team that is be able to decide whether testing is in a good condition to be frozen. It should also have option to adapt their time planing to the team's responses to "what are your plans for stable+1?" mails or to events that can't be known a few weeks after the prior stable release has happened. > That is the case because, as history has taught us, announcing a freeze > date and not respecting it Avoiding not respecting announced time frames or dates should not be that hard. > ---or, equivalently, have announced freeze > dates which are generally believed to be only indications---will spread > frustration among developers. This time frame could be rather imprecise at first and narrowed over time. > Freezing what? > -- > > The next question is then what does "freeze" means. Does it mean that > automatic transition to testing stops automatically at freeze date, This seems to be suboptimal (probably it's just your wording). The following quote from a mail sent by the release team in 2008 describes how it also has been handled for Squeeze: | Packages that are present in unstable the day we freeze will be | automatically allowed into testing, that is, the freeze date ... does | not mean your package should be in testing by then, but only in | unstable. > All in all, I quite like the idea of a strict freeze date + a flexible > period during which exceptions are granted in a more liberal manner, as > it has happened for the first weeks after the Squeeze freeze. The basic idea of a more flexible period is great, but it was not properly communicated via debian-announce. > Freezing when? > -- > > A scheme that could work is deciding that we'
Re: Bug#619820: either bash or dash should be enough
* Russ Allbery [2011-03-28 17:20 -0700]: > Practically speaking, I think bash is going to have to remain essential. > There are innumerable scripts, package build rules, maintainer scripts, > and other things in Debian referencing /bin/bash without declaring a > dependency, ... I agree. > So, I think this reduces to whether or not dash needs to remain essential. > I personally think that our default /bin/sh shell should be essential, and > the reasons why we switched to dash for that still apply, so I'm > comfortable keeping it essential. If a user configures /bin/sh to point to bash, dash isn't used anymore[1], so there is no reason to have dash installed on this user's system. I think dash should remain in base and be installed by default. Reasons for this include pretended better boot performance and simplifying writing portable scripts with default configurations. I also think dash should become build-essential, otherwise ./configure might detect /bin/sh as bash on hosts with default configurations. For example, zgrep in Squeeze/i386 uses /bin/bash in it's shebang line, but would use /bin/sh if it would have pointed to bash whilst ./configure has been run. But I do not think dash should remain essential. Before this could be changed, the mechanism how /bin/sh is handled should be improved (there are two according RC bugs in dash and two important ones in bash). > The problem with instead making "sh" essential is that we'd have to be > very careful about what was allowed to Provide sh. Given that bash would provide sh and stay essential, additionally making sh essential wouldn't archive anything (or I do not understand what you meant by 'making "sh" essential'). > Other people have discovered, for example, that zsh as /bin/sh has > interesting and surprising issues that can break software that > otherwise works with more common /bin/sh shells. Grml used zsh as /bin/sh but switched to bash and later to dash[2]. Some other shells in Debian, e.g., mksh, don't seem to have such surprising issues when used as /bin/sh. Regards Carsten [1] unless there are really scripts in Debian that use dash in the shebang line [2] http://grml.org/faq/#zsh_binsh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110329055131.ga25...@furrball.stateful.de
Re: Meeting Minutes, FTPMaster meeting March 2011
Hi, are there any news about leaf packages and the new field "mainpackage:"? If so, will Wheezy contain packages using this new field? Did you decide about throwing away DD built binaries? * Joerg Jaspert [2011-03-27 10:56 +0200]: > - We had some discussion about accepting ddebs into the archive but it > needs major changes to dak. We might accept them into experimental as > a first step for early testing but there is no code yet to support > this. I assume you strongly prefer implementing ddebs the way it was worked on during a Google summer of code 2009 project (which was the only sane long-term solution for Debian before throwing away uploaded binary packages was discussed) over the way Ubuntu generates ddebs since a few years. Is this correct? The related questions Emil Langrock asked in [1] are still open: | What is the direction we should follow for Wheezy[5]? Should we remove | our special -dbg packages or at least stop to create new -dbg | packages? Regards Carsten [1] http://lists.debian.org/debian-devel/2011/03/msg00376.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110327114938.ga25...@furrball.stateful.de
Bug#619785: Please move logsave to sysvinit-utils
Package: sysvinit-utils Severity: wishlist * Ted Ts'o [2011-03-26 19:07 -0400]: > There are similar, although less serious, issues with filefrag -v > (which will work on other file systems), but which also has some > ext2/3/4 specific code it in. badblocks is also linked against libext2fs. > Another binary which is used by other packages includes the logsave > utility, which is also in e2fsprogs, and which is used by > /etc/init.d/checkfs.sh and /etc/init.d/checkroot.sh in the initscripts > package. Debian supports (or rather will probably support) three init systems: * systemd does not use logsave to save the fsck log if /var/log is not mounted yet, but instead "just pipes the stdout of fsck to syslog which ends up in dmesg if syslog is not yet running" (thanks to whoever explained this in #systemd). * sysvinit and upstart depend on the package initscripts, which depends on sysvinit-utils. logsave does not use any libraries except libc. Provided that Ted Ts'o agrees, please consider moving logsave to sysvinit-utils. Regards Carsten P.S.: There is already a bug about essentialness filed against e2fsprogs: #474540 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110327001926.ga12...@furrball.stateful.de
Re: oops I sent a courtesy copy in violation of the code of conduct
* Carsten Hey [2011-03-12 10:50 +0100]: > There are examples where we lost potential future maintainers because > they never received a reply to an RFS. These replies were sent to the > list, but they were not sent to those requesting sponsorship. To clarify this: the problem was not that Mail-Followup-To: has been ignored, but the partly insane code of conduct. How should new people know that they don't get a copy of replies to their messages unless they explicitly request one? Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110312115729.gb17...@furrball.stateful.de
Re: oops I sent a courtesy copy in violation of the code of conduct
* jida...@jidanni.org [2011-03-12 11:14 +0800]: > Recently I replied to a certain message on this list with my familiar > S W runs the command gnus-summary-wide-reply-with-original > keystrokes, only to receive > > >I'm subscribed to the list, no need to CC me: > >http://www.debian.org/MailingLists/#codeofconduct > >No need to reply to this message. > > ... I set Mail-Followup-To: on every mail I send to *@lists.debian.org. Most DDs just ignore it (though there are some exceptions) and this renders using Mail-Followup-To: to get a copy to be rather useless. There are examples where we lost potential future maintainers because they never received a reply to an RFS. These replies were sent to the list, but they were not sent to those requesting sponsorship. > Therefore perhaps > http://www.debian.org/MailingLists/#codeofconduct > could be amended to mention that adding a Mail-Followup-To header might > add an additional wall of defense for those who wish to cut down even > further the possibility they might receive a courtesy copy from the less > technically adept. I agree. If a message I reply to contains a Mail-Followup-To: set, I use it. If not, I guess if the person I reply to wants to receive a reply. To prevent me to Cc: you, you need to explicitly set Mail-Followup-To: to the list. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110312095003.ga17...@furrball.stateful.de
Re: new scripts and patches for devscripts
* Stefano Zacchiroli [2011-03-11 00:18 +0100]: > First of all, I'm not sure anymore that I see the point of discussing > the *language issue* in a circle larger than the devscripts > maintainers. ... The language issue should probably be a decision > within the devscripts team, together with the script proposers. Wise words. > Nevertheless, I think the argument you're proposing above is potentially > dangerous. You seem to assume that just because some new scripts get > into devscripts then it will be up to the most active maintainer of the > package to maintain them. ... Debian is a do-ocracy and every DD governs his or her small country ;) I was talking about who should decide such things (not how specific teams work internally) and described a way to avoid working together on one package if there is no agreement. > IMHO, part of the value of devscripts is that it offers a bunch of > useful maintenance script by default. It's already quite big and very > few maintainers know all of them. Splitting the package even more will > further reduce the possibility that maintainers will find them. There is a similar argument for changing the current state: having generally useful scripts in ubuntu-dev-tools "reduce(s) the possibility that maintainers will find them" since the Ubuntu specific ones and those that assume Ubuntu typical configurations cause a lot of noise. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110311003034.gn31...@furrball.stateful.de
Re: new scripts and patches for devscripts
* Stefano Zacchiroli [2011-03-10 18:48 +0100]: > The argument of maintenance burden is in general a valid one, but IME > maintenance burden in devscripts is more limited by the amount of > people who are interested in maintaining a specific (dev)script than > by the needed language knowledge. ... > > To conclude with an obvious argument, rewriting useful tools which are > known to work and which are currently maintained by a derived distro, > when they are already written in a popular language, doesn't seem to > be the smartest thing to do to me. I agree with above arguments, but my conclusion is a different one than what you seem to imply in yours. James Vega seems to be the most active devscripts maintainer these days, and he does this (as far as I know) in his spare time. If he does not want to have python scripts in it, I see no justification to force him to do so. I also see no reason to try hard to convince him after he clearly stated his point of view. One way to have both, all members of the devscripts team keep their current vim in maintaining it, and not wasting the potential developer resources of these two DDs, could be the following: Package: devscripts Maintainer: Devscripts Devel Team Recommends: devscripts-python Package: devscripts-python Maintainer: Devscripts Python Devel Team Recommends: devscripts If including other languages in the new package would be planned, naming it devscripts-extra or similar instead could be helpful. An alternative to the above is to rename devscripts to devscripts-base or -core, name the new binary package devscripts and let it depend on devscripts-base. If the devscripts maintainers would change their mind in future, these packages could be merged. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310191522.ga10...@furrball.stateful.de
Re: Automatic debug packages
* Philipp Kern [2011-03-08 16:30 +]: > On 2011-03-08, Carsten Hey wrote: > > A prerequisite to automatically add debug packages for all > > architectures is to change the way how packages are uploaded and/or > > build[1]. In the upcoming ftpmaster meeting[2] from the 21st until > > the 27th of March, one possible way to change it (or rather a part > > of it) will be discussed: > > I don't think that's true. In fact I also suggested back then that it > should "just" part of the normal build process. Then DDs would upload > ddebs just like the buildds would. I read that there are plans to work on translation packages (TDeps) before Wheezy is released. Adding TDeps to Debian is in many aspects similar to adding automatic debug packages (DDeps). Given an reasonable abstract view on the possible implementations of both, they can be grouped into: * An upload by a DD includes all additional packages. Whether DD uploaded packages are thrown away does not matter. This is the variant you mentioned. * An upload by a DD does not include additional packages. DD uploaded packages are used. Additional packages are created on the Debian infrastructure: - DDeps: DD uploaded packages are rebuilt to extract debugging packages, the resulting binary package is thrown away. debug.debian.net is an implementation of this. - TDeps: The message catalog is extracted from the uploaded binary package (or it is rebuilt, but this would be pointless) and the binary package is repacked. * An upload by a DD does not include additional packages. DD uploaded packages are thrown away and rebuilt. Ubuntu does this (or rather something equivalent) since ages to create debug packages. Using implementations from the same group for DDeps and TDeps seems to be a sane choice. > The throw-away part isn't really connected with that. If we decide to use a implementation from the first or the second group, the throw-away part is indeed not connected with that. If we decide to use a implementation from the third group, the throw-away part is a prerequisite. Before the throw-away part is decided, discussing the different ways of implementing and choosing one could be a waste of time. Questions to consider during such a discussion include: * Do we want users which build private packages to build also DDeps and TDeps? * Do we want to have a different building process (or build options) for to be uploaded packages? Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110308234028.ga27...@furrball.stateful.de
Re: Automatic debug packages
* Emil Langrock [2011-03-08 00:48 +0100]: > I browsed a little bit in the goals which were planned for squeeze and noticed > that the debug packages aka ddebs[1] weren't implemented in the debian > infrastructure. A prerequisite to automatically add debug packages for all architectures is to change the way how packages are uploaded and/or build[1]. In the upcoming ftpmaster meeting[2] from the 21st until the 27th of March, one possible way to change it (or rather a part of it) will be discussed: | * Throwaway DD built .debs (well, let's have the fight^Wdiscussion) I suggest further discussing debug packages after we know the result of the ftpmaster meeting. I also suggest to add discussing the required changes for automatic debug packages on ftpmaster side to the meeting's agenda. Regards Carsten [1] Currently a Debian Developer/Maintainer builds locally and uploads the source package and one binary package. Then the build daemons build binary packages for the other architectures. Finally, all build packages become part of the archive. [2] http://lists.debian.org/debian-devel/2011/02/msg00064.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110308150518.ga21...@furrball.stateful.de
Re: potential MBF: first alternate depends not available in main
* Paul Wise [2011-03-04 12:54 +0800]: > On Thu, Mar 3, 2011 at 10:28 PM, Carsten Hey wrote: > > >> But, anyway, I believe that the first depends of an alternate depends > >> relation > >> should be available in main and propose to file bugs about this. > >> > >> Do you agree this warrants a mass bug filing? I couldn't find this written > >> out > >> in policy ... > > > > If the is a consensus, it could be added to the developer's reference or > > the policy. > > Debian Policy section 2.2.1 already covers this: > > ...the package must not declare a "Depends", "Recommends", or > "Build-Depends" relationship on a non-main package. > > http://www.debian.org/doc/debian-policy/ch-archive.html#s-main This can be read in different ways: * All of the alternatives must be in main. * The first alternative must be in main. * One of the alternatives must be in main. Before the Ubuntu main inclusion requirements had been clarified in January, they have at least once wrongly been read as "All of ...". There are many dependencies on, e.g., openjdk-6-jre | sun-java6-jre, in Debian which would violate policy if all of the alternatives would need to be in main. I hope we agree that the first mentioned way to read this section is not how the current policy should be interpreted and think that a clarification could improve the policy. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110304121636.ga20...@furrball.stateful.de
Re: potential MBF: first alternate depends not available in main
* Holger Levsen [2011-02-28 16:05 +0100]: > piuparts in master-slave mode currently cannot test packages which first > alternate depends is not available in main, ie the secvpn package depends > on "adduser, bc, ssh, ppp, timeout | coreutils (>= 7.5-1), sudo" and timeout > is only available in lenny and etch, thus piuparts cannot test secvpn in > squeeze, wheezy and sid. That's a bug in piuparts. > > Another popular example is a depends on "apache | apache2"... Martin Pitt implemented a script[1] that tests for a similar package relationship problem in Ubuntu main[2]: | All build and binary dependencies (including Recommends:) must be | satisfyable in main (i. e. the preferred alternative must be in main). > But, anyway, I believe that the first depends of an alternate depends relation > should be available in main and propose to file bugs about this. > > Do you agree this warrants a mass bug filing? I couldn't find this written out > in policy ... If the is a consensus, it could be added to the developer's reference or the policy. Regards Carsten [1] http://www.piware.de/2011/01/new-tool-to-check-support-status-of-dependencies/ [2] https://wiki.ubuntu.com/UbuntuMainInclusionRequirements -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110303142813.gb29...@furrball.stateful.de
Re: Help identify packages that multiarch support will break
* Raphael Hertzog [2011-03-02 15:06 +0100]: >In general parsing the status file should not be done, instead you >should use dpkg-query. Is there any reason for this, except that the format of the status files will evolve? >You should use "dpkg-query --control-path " to Jftr, there is a lot potential for performance improvements in dpkg-query, some queries can be done way faster even in gawk. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110303130456.ga29...@furrball.stateful.de
Re: Cedilla removed from sid, users complain
* Andrey Rahmatullin [2011-01-25 23:36 +0500]: > On Tue, Jan 25, 2011 at 07:14:39PM +0100, Juliusz Chroboczek wrote: > > I'm upstream for Cedilla [1,2], which has been orphaned and removed from > > Sid. I'm receiving e-mail from Debian users of Cedilla, asking me what > > is the suggested replacement. What shall I answer? > See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610903 The package that would have been released with Squeeze if it wouldn't have been orphaned is still available: http://snapshot.debian.org/package/cedilla/0.6%2B20090614-1/ Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110125224729.ga15...@furrball.stateful.de
Re: using perl in preinst script
* Philipp Kern [2010-12-29 05:38 +]: > On 2010-12-28, Carsten Hey wrote: > > ... One reason for this is that dpkg's perl scripts were rewritten > > in C. > > I know you phrased it differently but wasn't the motivation for this > rewrite to be more robust in the base system on upgrades? I.e. do not > rely on Perl and thus avoid adding more contraints on how the base > upgrade must be performed to keep dpkg working properly. I don't know what the main motivation was, although making upgrades more robust seems to be a possible and a good one. http://wiki.debian.org/Teams/Dpkg/RoadMap says: | Make dpkg.deb contain only sh and C programs (to help embedded | distros, to make it possible to remove perl-base from essential) Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101231005641.ga6...@furrball.stateful.de
Re: using perl in preinst script
* Steve Langasek [2010-12-28 15:46 -0800]: > On Tue, Dec 28, 2010 at 11:48:18PM +0100, Carsten Hey wrote: > > * pam_getenv and pam-auth-update from libpam-runtime: > > >pam_getenv is 76 lines of code. pam-auth-update is 490 lines of > >code and has been added after Lenny has been released. > > And the lack of pam-auth-update has been a glaring gap in Debian > functionality for the better part of a decade before that. I'm not > dropping pam-auth-update from the package, and I'm not rewriting it in > C or in shell ... I neither suggested dropping it nor that you should rewrite it and did not question that it is useful. If existing perl scripts would be rewritten, this would be something to be done by people wanting to make perl non-essential in agreement with the according maintainers. Also I did not say that perl-base should be made non-essential, I did list what is missing from being able to do so. > > > I cannot imagine this ever happening at a practical level. > > > Not if people continue to add new perl scripts to essential and to write > > new preinst scripts in perl. > > Which there is zero reason for anyone to go out of their way to avoid doing. One reason would be to avoid a possible later rewrite (in python and done by you in your case) if it would be decided that perl-base should be made non-essential in future. This was not meant as attack or to let libpam-runtime appear as bad example (which it is not), I wanted to point that if there are plans to make perl-base non-essential, then we should all avoid doing things that would make fulfilling this plan more difficult and if there is no such plan, than there is no point in avoiding writing preinst or postrm scripts in perl or avoiding to use perl in essential packages. Due to the missing consensus there is currently no right or wrong and the most sane thing is to assume that everything stays as it is now. This missing consensus leads to more workload, either for people avoiding perl in maintainer scripts and essential packages because they wrongly assume that perl-base might become non-essential, or because of writing perl scripts that are going to be replaced by implementations in other languages. > I don't see any way that it would benefit Debian to drop perl from the base > system and limit ourselves to C, C++, and shell as implementation languages. There are advantages of having a small minimal Debian installation (i.e., essential + apt), but there are more worthwhile things to do than removing a language from essential to save 4 MB. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101229015255.gb31...@furrball.stateful.de
Re: using perl in preinst script
* Russ Allbery [2010-12-27 08:49 -0800]: > Luk Claes writes: > > > I thought there were some plans to try to get rid of perl-base being > > essential, in that case only shell (or C?) is a real alternative. We are not that far away from being able to implement this plan. One reason for this is that dpkg's perl scripts were rewritten in C. After debootstraping the minbase variant of sid, installing file-rc and removing insserv, there is not much perl left in the newly created system. The remaining perl library packages could be removed after installing debconf-english. Remaining perl scripts are: * chkdupexe from util-linux: This is short and could easily be replaced by something written in C. Alternatively, the following untested snippet could be prepended to chkdupexe: #!/bin/sh [ -x /usr/bin/perl ] && exec perl -x -- "$0" "$@" echo >&2 "Please install the package perl-base." exit 1 * debconf: cdebconf exists and there is bug #328498 about switching to cdebconf as default, blocked by four other bugs. * pam_getenv and pam-auth-update from libpam-runtime: pam_getenv is 76 lines of code. pam-auth-update is 490 lines of code and has been added after Lenny has been released. Additionally, the preinst and postrm scripts of linux-image-* are written in perl and kernel-package generates packages with perl maintainer scripts. Using debhelper to add the dependencies on perl-base for packages that need them could reduce the required effort. Doing this early would ease ensuring sane upgrade paths. > I cannot imagine this ever happening at a practical level. Not if people continue to add new perl scripts to essential and to write new preinst scripts in perl. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101228224818.ga23...@furrball.stateful.de
Re: xsnow
* Klaus Ethgen [2010-12-02 23:11 +0100]: > Unfortunately I am no debian developer so I cannot take the package. Actually, you could maintain a package. You would just need a sponsor for your uploads. Please read the following URL for further information about finding out if the old maintainer is inactive and how to become maintainer if he is: http://www.debian.org/doc/developers-reference/beyond-pkging.html#mia-qa Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101202231425.ga29...@furrball.stateful.de
Re: Debian Installer 6.0 Beta1 release (WPA support)
* Philipp Kern [2010-11-06 10:03 +]: > Ubuntu's alternate installer doesn't support it neither. It only applies > to the netinst case, too, which Ubuntu doesn't offer as prominently. If one of Ubuntu's installers does support WPA, I guess they also translated their WPA related strings. Wouldn't it be possible to use the same stings and their existing translations for those? Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101106182529.ga16...@foghorn.stateful.de
Re: [RFC] disabled root account / distinct group for users with administrative privileges
* Simon McVittie [2010-10-22 12:10 +0100]: > On Fri, 22 Oct 2010 at 11:44:31 +0100, Ian Jackson wrote: > > I wouldn't be at all surprised to find that "priv" was occasionally > > used as a username for an ordinary user. > > If I saw it out of context I'd also tend to assume that "priv" is > short for "private" instead of "privileged", but perhaps that's just > me. No, it isn't just you, I thought that it could also mean 'private', too. 'prvl' or similar would look like it would have been generated by pwgen. It doesn't look like a short, unambiguous and pronounceable abbreviation for 'privileged' exists and 'sysadmins' seems to be a better choice than 'privileged' or 'privileges'. My favorites up to now are 'sysadmins' and 'sudoroot', although I don't like having the command as part of the groupname. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101022174232.ga17...@foghorn.stateful.de
Re: [RFC] disabled root account / distinct group for users with administrative privileges
* Russ Allbery [2010-10-21 02:37 -0700]: > I like sudoroot, personally, but I think sudo is probably okay. A group named sudo or sudoroot is somehow linked to sudo as tool used to gain administrative privileges. No one knows if in future an other tool will be the de facto standard to gain privileges, as sudo is now, and having a group sudoroot whose members are allowed to gain to become root using an imaginary suto command sounds wrong. > Really, ideally, this is something that would be standardized across > distributions. I think, especially if we think about cross distribution standardisation we should choose a name that is independent from implementation details like command names. The subject of this thread summarizes the purpose of this group quite well: ... / distinct group for users with administrative privileges ^ ^^ As admin already has been discussed and some people raised possible disadvantages, what about using an abbreviation of the word privileges, i.e., priv as group name? > Yeah, that's the argument for using something relatively obscure, ... priv should be obscure enough ;) Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101021225641.ga11...@foghorn.stateful.de
Re: Is a bug RC relevant if it has an influence on the health of a person
* Karsten Hilbert [2010-09-09 13:07 +0200]: > Filed a bug: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596219 > > but reportbug did not let me specify either of RC / critical > / grave / serious / security ... I just set this to serious. It may take some minutes until the BTS is updated accordingly. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100909114357.ga29...@foghorn.stateful.de
Re: Activating t-p-u by default (was: Re: For those who care about their packages in Debian)
* David Kalnischkies [2010-08-28 16:23 +0200]: > 2010/8/26 Carsten Hey : > > * David Kalnischkies [2010-08-26 17:43 +0200]: > >> Long story short: > >> If you want to get updates from an archive only if you pushed a version > >> previously from it: 100 => pin > 500. > > > > Wouldn't adding a new field to Release files similar to 'Not-Automatic' > > but pin to 101 instead of 1 if this new field is set to yes an option > > for apt/Squeeze+1? This has been reported in #186767. > > Well, yes and no. > Technical more or less no problem, but… > > As far as i understand t-p-u i don't understand why the default should > be < 500. ... I also don't think t-p-u should be pinned between 100 and 500 per default, but nobody disagreed and I would prefer a different approach that does not involve activating t-p-u per default (as suggested in another mail in this thread). > The problem with this is also, which is why i don't think it would be > suitable for backports, is that these archives mixing minor only-bugfix > releases and new groundbreaking upstream releases… Mixing is the only way to handle backports.org without additional people working on it (a lot of people ...). > E.g.: I maybe want to get bugfix releases for iceweasel through backports > automatically, but what i don't want is an automatic 3.6 -> 4.0 upgrade, > but such pinning i need to define by hand anyway. You won't get security fixes this way. A user could decide on case by case basis if he or she wants to upgrade, but this requires a deep understanding of security issues and should IMHO not be default. Users that are aware of these issues could of course still change the pinning to the value they consider to be useful for them. > Regarding the bug: What do you do if two non-debian archives provide such > a package -- and, do they "fight" against each other now that they can by > changing their DefaultPriority? I think the proposed DefaultPriority was a wrong approach, there should be one below 100 (NotAutomatic), one between 100 and 500 (the one that we are discussing right now) and the default 500 "normal" archives have. > The cleaner way for the user would it be to declare: I don't want to > get this package from this archive ever and i care only for these > packages from this archive, ignore the rest. You can say that with -1 > and Co, but it is a bit harder than needed… All I want is sane defaults, users that use their systems in non-default ways should configure their systems, not most users. > So, again in short: > I don't see a reason backports shouldn't be pinned to 1 by default and > t-p-u by default not pinned at all to get the default 500 pin… We both aren't the ones to decide this in case of backports.org. I asked Alexander Wirt what he would think about such a feature. First response was that it must be available in stable to be used, then he said that it would not be uninteresing (in German "sicher faend ich das nicht uninteressant"). Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100831202454.ga4...@foghorn.stateful.de
Re: Activating t-p-u by default (was: Re: For those who care about their packages in Debian)
* David Kalnischkies [2010-08-26 17:43 +0200]: > Long story short: > If you want to get updates from an archive only if you pushed a version > previously from it: 100 => pin > 500. Wouldn't adding a new field to Release files similar to 'Not-Automatic' but pin to 101 instead of 1 if this new field is set to yes an option for apt/Squeeze+1? This has been reported in #186767. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100826165806.ga25...@foghorn.stateful.de
unstable-proposed-updates (was: For those who care about their packages in Debian)
* Ian Jackson [2010-08-25 13:42 +0100]: > Perhaps the right answer is to simply ask people to upload > non-release-related stuff to experimental rather than unstable. That > way one can do the itch-scratching right away; moving packages from > experimental to unstable later is easy ... > > Even better would be an option to write something in your .dsc which > would cause automatic transfer of your package into unstable when > testing is unfrozen. Distro target of "experimental-unstable" > perhaps. That way we could automate the "flood of new packages and > distro is totally broken" effect :-). I thought about something like this a while ago and would have called it 'unstable-proposed-updates'. Currently experimental is used for both, experimental packages and packages the should go to unstable in future, a new suite to split this would it make possible to differentiate between really experimental and other packages. Possible advantages of having unstable-proposed-updates: * During a freeze, people could continue to upload new versions without the need to use t-p-u if they need to get fixes to testing. For example, this would have prevented a broken libpam-mount from entering lenny during freeze. A (semi?) automatic migration to unstable after the freeze (maybe in batches) would save the maintainers some work. Maintainers could still use experimental instead for their packages if they don't like this automatism. * CUT could get updates through u-p-u instead of unstable during freeze (currently unstable often misses new upstream versions in that time and alternatively letting packages migrate from experimental wouldn't be the best idea because some of the packages could really be experimental). * Maybe it could also be helpful to coordinate transitions, the release team would then just move packages from u-p-u to unstable when they think it is the right time. Additionally they could set triggers that would automatically move specific packages to u-p-u instead of unstable when they are uploaded. The release team knows best if this would help them ;) * Russ Allbery [2010-08-25 01:13 -0700]: > Yves-Alexis Perez writes: > > Would it be possible (at one point) to “fix” it and stop using > > unstable as t-p-u and experimental as unstable when freeze is in > > action? > > We could try to get lots of people who normally use unstable to > instead test testing plus t-p-u, but I'm not sure they'd be willing to > do so. I for example don't want to switch my unstable systems to > testing plus t-p-u for a variety of reasons. I think this point is important, people will not switch to the distribution we think they should use in specific release phases. This is also the reason why I don't think things like adding another distribution between stable and testing or testing and unstable would have the desired effect. Instead we should ensure that what we have (testing and unstable) contains what we want most of our non-stable users to use and test. If there would be a good reason to add t-p-o or u-p-o to their sources.list, then I think some users would do so, but I expect this still to be the minority. One such reason to add u-p-o could be that they want to use newer software than what is currently available in unstable. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100825232007.ga20...@foghorn.stateful.de
Re: Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files
* David Claughton [2010-08-15 01:33 +0100]:
> Another use-case might be to remove "convenience copies" of system
> libraries. Might be useful (e.g. for security reasons) to be able to
> guarantee that this code isn't being accidentally used by a build (in
> a way that can be easily checked by a script).
Half a year ago wml and related packages had such bugs. To create
a list of unused files [1] I used a few lines of shell [2] ... pasting
the relevant part of it might be easier than explaining it:
# List a Debian source package's files that are not accessed during
# building the package. File systems must be mounted with atime or
# relatime.
...
# File systems mounted with relatime only update access time if it
# is earlier than or equal to the modify or create time, thus touch
# every regular file.
find . -type f -exec touch '{}' ';'
...
touch "$TMPFILE"
sleep 1
dpkg-buildpackage -D -tc -rfakeroot -us -uc -b
...
find . -type f ! -anewer "$TMPFILE" | sort | tee "$LOGFILE"
Axel found it useful at that time, but the use case seems to be quite
narrow.
Regards
Carsten
[1]
http://stateful.de/~carsten/tmp/100216NxxyjuNgtqk/wml-2.0.11ds1_unused-files_24941.log
[2] http://stateful.de/~carsten/tmp/100216NxxyjuNgtqk/orig-unused-files
(These URL's are temporary)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100818075543.ga...@foghorn.stateful.de
Re: Recent changes in dpkg
* Carsten Hey [2010-05-27 15:44 +0200]: > * Mike Hommey [2010-05-27 12:00 +0200]: > > There is one possible benefit: impossibility to create a native package > > when the .orig.tar.gz is missing, which happens much too often. > > Doesn't look like it's impossible: > > | dpkg-source: info: source format `3.0 (quilt)' discarded: no orig.tar file > found > | dpkg-source: info: using source format `1.0' You're right if a newer dpkg is used: | dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527134738.gb8...@foghorn.stateful.de
Re: Recent changes in dpkg
* Mike Hommey [2010-05-27 12:00 +0200]: > There is one possible benefit: impossibility to create a native package > when the .orig.tar.gz is missing, which happens much too often. Doesn't look like it's impossible: | dpkg-source: info: source format `3.0 (quilt)' discarded: no orig.tar file found | dpkg-source: info: using source format `1.0' Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527134440.ga28...@foghorn.stateful.de
Re: Best practices for development workstations
* John Goerzen [2010-03-29 19:03 -0500]: > Suggestions? Sounds like you should consider trying vserver or similar. It consumes less resources than "real virtualisation" but provides better networking isolation than simple chroots. You would need a kernel with vserver support (Debian provides some for lenny and squeeze), util-vserver and vserver-debiantools. The commands newvserver and vserver are sufficient to begin. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100405214020.ga25...@foghorn.stateful.de
Re: [RFC] DEP-6: Meta-Package debian/control field
Besides sane handling of metapackages we should also think about marking transitional packages in some way. This would enable higher level tools like apt to mark them as automatically installed and thus get rid of useless packages if no other package depends on them. The dependencies of these transitional packages would be marked as manually installed if the transitional package was marked as manually installed. deborphan tries to detect such packages by checking if a short description contains the words "dummy" or "transitional". This hack is ok for deborphan but should not be adopted by apt. On Mon, Dec 21, 2009 at 07:52:22AM -0800, Steve Langasek wrote: > This could be done with special handling of 'Section: metapackages', > or by adding a new 'Metapackage: yes' field (as I think some would > prefer based on comments on IRC). Instead of adding various new fields we could use debtags for non-essential information to be used by higher level packaging tools, e.g. metapackages or transitional packages. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Tue, Nov 24, 2009 at 01:53:34AM +0100, Carsten Hey wrote:
> On Mon, Nov 23, 2009 at 09:50:15AM +0100, Raphael Hertzog wrote:
> > For each patch:
> > - ...
> >
> > Note: this works only if quilt is not installed (or if you ensure
> > dpkg-source is called with --without-quilt which you currently can't pass
> > via dpkg-buildpackage).
>
> JFTR, is also works with quilt installed, given that you don't rename
> applied patches.
>
> The following shell function automates the required quilt pop/push and
> the adjustment of the series file:
>
> dquilt-rename() {
> ...
> }
Or just use quilt rename instead ;)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Mon, Nov 23, 2009 at 09:50:15AM +0100, Raphael Hertzog wrote:
> For each patch:
> - apply patch
> - dpkg-buildpackage -S
> - rename debian/patches/debian-changes- into something else
>and edit its headers
> - fix debian/patches/series
>
> Note: this works only if quilt is not installed (or if you ensure
> dpkg-source is called with --without-quilt which you currently can't pass
> via dpkg-buildpackage).
JFTR, is also works with quilt installed, given that you don't rename
applied patches.
The following shell function automates the required quilt pop/push and
the adjustment of the series file:
dquilt-rename() {
(
source $HOME/.quiltrc;
cd "${QUILT_PATCHES:-patches}";
j=`quilt applied | wc -l`;
quilt pop -a;
if [ -f "$1" ] && ! [ -f "$2" ];
then
mv "$1" "$2";
sed -i "s/^$1\$/$2/" series;
fi;
for i in $(seq $j); do
quilt push || [ $? eq 2 ] || return 1;
done
)
}
I just wrote it and only ran it once, so don't expect it to be mature.
It requires the snippet given in /usr/share/doc/quilt/README.source as
$HOME/.quiltrc.
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#535501: ITP: roxterm -- A multi-tabbed GTK terminal emulator
On Thu, Jul 02, 2009 at 06:36:37PM +0100, Tony Houghton wrote: > Package: wnpp > Severity: wishlist > Owner: Tony Houghton Please rename the existing RFA bug (#535246) instead of filing a new one, e.g. by using /usr/bin/bts from the package devscripts. > Upstream Author : Tony Houghton And please _don't_ upload a native package ;) debian-ment...@lists.debian.org and #debian-mentors on irc.oftc.net are good places to find sponsors or ask questions. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Tue, Jun 16, 2009 at 10:05:40AM +0100, Mark Brown wrote: > On Mon, Jun 15, 2009 at 11:31:51PM +0200, Carsten Hey wrote: > > If an integration of the information in the patch headers into UDD would > > be planned which could be used to query patches not applied upstream or > > similar, I would at least see a benefit in using a standard header > > format. > > That's the idea - make the data available for software. Well, which software, which use case? You don't need a special format to display headers in the Debian patch tracking system. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 10:15:16PM +0100, Mark Brown wrote: > On Mon, Jun 15, 2009 at 11:10:14PM +0200, Carsten Hey wrote: > > > I currently don't see a relevant benefit in this above just using the > > changelog entry, which you need to write anyway. Additional information > > Putting the information in the changelog makes it much harder to find Yes, putting the information _only_ in the changelog make it much harder to find, but that is not what I did nor what I proposed. As you can see, my patch header is a copy of the changelog entry, so you don't even need to open the changelog file to get all relevant information. I proposed a free text format which should include specified information, whether this is a git like header, a copy of the changelog entry or anything else does not matter as long as it is readable and understandable. If an integration of the information in the patch headers into UDD would be planned which could be used to query patches not applied upstream or similar, I would at least see a benefit in using a standard header format. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote: > please find below a first draft of DEP-3 that I called Patch Tagging > Guidelines. The idea is to standardize a set of meta-information to embed > in patches that we apply. Please review, share your comments and ideas of > enhancements. I currently don't see a relevant benefit in this above just using the changelog entry, which you need to write anyway. Additional information like the author of the patch or a note like "this is Debian specific, don't merge" can also be included in a changelog file if this is relevant, as I did in the following example: debian/changelog: pal (0.4.3-2) unstable; urgency=low * debian/watch: use QA redirector. * Added a new Debian specific patch which changes the path to example.css in pal.1. Debian installs this file into a different location than upstream's makefile target install-doc. (Closes: #497874) -- Carsten Hey Sat, 06 Sep 2008 07:13:08 +0200 debian/patches/50_debian_fix_example_path_in_manpage.patch: pal (0.4.3-2) * Added a new Debian specific patch which changes the path to example.css in pal.1. Debian installs this file into a different location than upstream's makefile target install-doc. (Closes: #497874) --- pal.orig/pal.1.template ... If you get the relevant information from git or any other source this is in my opinion also ok, as long as the header format is easy to parse for humans. Standardizing the format would be a must if this information should be parsed by computers, do you have any plans in this direction? I think there should be a consent _which_ information should be included in patch headers, but unless they must be parsed by machines a standard which defines _how_ these information should be presented just adds unnecessary work for the maintainers. For a definition which information should be in a header your proposal could act as a very good basis, but there should IMHO some defaults which fit in most cases, e.g. when no author is mentioned the current Debian maintainer is the author and the patch is assumed to be Debian originated unless noted otherwise. > - in format "3.0 (quilt)" dpkg-source would create initial headers > respecting this format automatically based on the changelog when it > creates a new patch Not everyone lets dpkg create new patches. Different maintainers, different workflows ... Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
On Wed, Jun 03, 2009 at 02:59:52PM +0200, Marco d'Itri wrote: > > On Jun 03, Carsten Hey wrote: > > > On Mon, Jun 01, 2009 at 03:50:50PM +0200, Josselin Mouette wrote: > > Nowadays, you cannot use your system if you don’t use udev, so this > > is irrelevant. > > > > I'm writing this mail from a system without udev: > > Yes, and nobody cares much. Correct, it just shows that "your argument is irrelevant because you can't use a system without udev" is wrong, at least for lenny. Someone wrote a while ago: > Debian ... will be easy to keep up-to-date with a 'upgrading' script > in the base system which will allow complete integration of upgrade > packages. How do you plan to ensure that upgrading from one stable release to the next is possible after deprecating /usr as a separate partition? Or do you plan to force all the systems using a separate /usr to be reinstalled whilst being upgraded to squeeze+n? Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
On Mon, Jun 01, 2009 at 03:50:50PM +0200, Josselin Mouette wrote: > Nowadays, you cannot use your system if you don’t use udev, so this is > irrelevant. I'm writing this mail from a system without udev: $ cat /proc/version Linux version 2.6.26-1-vserver-686 (Debian 2.6.26-12) (wa...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-24)) #1 SMP Mon Dec 15 21:11:05 UTC 2008 $ dpkg -s udev | grep Status Status: unknown ok not-installed $ dpkg -s yaird | grep Status Status: install ok installed (Yes, I need to reboot ...) Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Possible mass bug filing: non-doc packages recommending doc packages
On Fri, May 08, 2009 at 04:06:47PM +0200, Cyril Brulebois wrote: > Daniel Burrows (07/05/2009): > > As a practical matter, downgrading these dependencies will cause > > aptitude and other package managers to believe that the documentation > > is unnecessary and suggest removing it. > > So that one has a chance to notice possibly unneeded doc? Works for me. You don't need to wait for these dependencies to be changed to notice possibly unneeded docs: deborphan -n --guess-doc | grep -- '-doc$' The need to grep for doc packages for this use case can be avoided after a option to ignore libraries has been be added to deborphan, which will happen when tags replace sections in Debian or, if requested, earlier. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508644: new release goal default-mta? (was: stable-p-u: mdadm 2.6.7.2-2)
On Tue, May 05, 2009 at 06:53:12AM +0200, martin f krafft wrote: > (updated mdadm coming to s-p-u on Thursday, are there other > comments? > http://lists.debian.org/debian-release/2009/05/msg00024.html) Depending on default-mta | mta in a upload to s-p-u does not fix anything since there is no default-mta in stable. This would possibly even break pinning in unexpected ways for users with stable and testing in their source.list. Thus please consider depending on exim4 | mta or postfix | mta in your upload to s-p-u and changing the dependency as discussed for your next upload to sid. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Want to work with a Linux Group
Hi, thank you for your interest in Debian. On Tue, Apr 14, 2009 at 10:32:13AM +, Roger Preston wrote: > I am keen to work for/with a Linux development group, though am not > sure where to start. Besides things like translating, maintaining the Debian website and reporting bugs there are basically two things Debian developers do, though these can not strictly be separated: packaging and programming. > I would describe myself as a competent C++ programmer, though perhaps > not quite at your levels yet. Alternatively to work on Debian you could also help to maintain software upstream, but you asked on this list, so I don't think this is an option for you. So I assume that you are interested in programming C++ or maintaining packages of software written in C++. The first step is to decide on which package you want to work. Mostly it is very helpful if you use the software you work on yourself and if you concentrate one one, at least at the beginning. There is some really big and complex software written in C++ in the Debian archive: * XULRunner, on which Iceweasel is based. Iceweasel is a rebranded Mozilla Firefox. Icedove (rebranded Thunderbird) also uses XUL, but I'm not sure if they use the same XULRunner. * Openoffice.org Their Debian packages need some help at the moment, though they require both good skills and some time to understand how they work. Other well known packages written in C++ are the KDE suite and apt. There is many more less known software written in C++ in Debian. apt is as far as I know the only package where Debian is upstream (together with Ubuntu) and which is written in C++, so trying to get involved in apt development might be an option for you. If you don't find a proper package in C++ then C might be an option. There are nearly uncountable packages using C in Debian, finding one you are interested in should not be a problem. There are different ways to call for help: * Orphaning a package (O) - a new maintainer is needed * Request for adoption (RFA) - a new maintainer is needed but the old one does the job until a new one is found * Request for help (RFH) - e.g. a second maintainer is wanted * Tag a bug help - the maintainer needs help with a specific bug The Debian bug tracking system has a list of the first three, since they are bug-reports filed against the pseudo package wnpp. The title of the bug tells you which kind of help was requested. Other things like RFP or ITA bugs are currently not interesting for you: http://bugs.debian.org/wnpp If you want to gain some experiences before you decided on which package you want to work you could send patches for bugs which are release critical (and older than just a few days) or where help has been requested. To get a list of packages you have installed and where help is requested please install the package devscripts and run wnpp-alert. A list of bugs filed against a package can be seen at http://bugs.debian.org/src:sourcepackagename, e.g.: http://bugs.debian.org/src:openoffice.org http://bugs.debian.org/src:xulrunner To get a list of single bugs needing help visit: http://bugs.debian.org/tag:help A list of release critical bugs can be found at: http://bugs.debian.org/release-critical/debian/all.html I could also provide you with some bugs in my packages which you could fix, but as already said, it's better when you are interested in the package and not someone else who just needs a coding slave. After you have found a package you want to work on the best way to get involved is to send patches for some bugs. Just a declaration of intent does not help very much because many people do this but they to not start working on what they proposed to do, this is the reason why you will not get an answer to such mails in most cases. If there is a mailing list or an irc channel where issues regarding your favorite package are discussed then joining this list or channel might be a good idea. The next step after you sent some patches asking the current maintainers to become a co-maintainer. If a package is orphaned there will be no contact person or someone who responds to your mails (except for xulrunner I guess), in such cases debian-ment...@lists.debian.org or #debian-mentors on irc.oftc.net can help you to become the new maintainer of the package. After maintaining or co-maintaining a few smaller packages or a bigger package for some time you can apply to become Debian Maintainer or Debian Developer. Some documents you should read can be found at: http://debian.org/devel/ The first one is probably http://debian.org/doc/maint-guide/, additionally http://www.debian.org/Bugs/ provides some information about our bug tracking system. > I would really appreciate it though if you could point me in the > direction of some Linux groups seeking development assistance. I hope my mail helps, if you have additional questions debian-ment...@lists.debian.org
Re: libcairo has two different versions in Lenny?
On Fri, Mar 20, 2009 at 07:47:41PM +, Neil McGovern wrote: > On Tue, Mar 17, 2009 at 12:57:25AM +0100, Michelle Konzack wrote: > > 920 cdrom://Lenny_DVD_1 lenny/main Packages > > 900 ftp://ftp2.de.debian.org lenny/main Packages > > 980 http://security.debian.org lenny/updates/main Packages > [...] > > Can someone explain, WHY the SECURITY mirror has an outdated version of > > libcairo2 and blocking the installation (I have manualy installed the > > libcairo2, but it is annoying and should be corrected as fast as > > possibel) > > > > You appear to have pinned things. As this is a list for Debian > Development, rather than basic user support, I would suggest you ask in > debian-us...@lists.debian.org. FUs set. This was an upload to testing-security which hit stable-security during the release. Such things are the reason why pinning stable-security with a higher priority than stable is not a good idea. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#519339: ITP: tmux -- an alternative to screen, licensed under 3-BSD
On Thu, Mar 12, 2009 at 11:17:02PM +0100, Guus Sliepen wrote: > On Thu, Mar 12, 2009 at 10:37:41PM +0100, Karl Ferdinand Ebert wrote: > > - a clearly-defined client-server model: windows are independent > > entities which may be attached simultaneously to multiple sessions > > and viewed from multiple clients (terminals), as well as moved > > freely between sessions within the same tmux server; > > I do not really see anything here that screen can't do... GNU screen can't move one window from one session to another or attach one window to two session. Regards, Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
On Sun, Mar 01, 2009 at 09:44:41PM -0800, Steve Langasek wrote: > You have a case here where the user has managed to run a complete > system for a non-negligible period of time without ever installing an > MTA (long enough to either configure oldstable in their sources.list, > or for the version of Debian they installed to *become* oldstable). > > Then the user tries to install a package that depends/recommends > default-mta | mail-transport-agent, and pulls in a default. Why does > the user care if this pulls in the one from oldstable vs. stable? (Imagine that we did this default-mta-foo years ago) He or she cares because the security support of exim will stop in less than a year and exim4 is a much more sane default than exim, especially for users who don't explicitly install their favorite mta since exim has an ugly pre-debconf initial configuration system. Also remember, that there is no upgrade path from exim to exim4 (release notes do not count here since the user read them months ago when he or she did the dist-upgrade and no one can expect that users remember every side note in them during the whole release cycle) and that the user can expect to to able to remove the old souces.list entry without bad things like no security support for their mta happening (he or she did already do a dist-upgrade with the release notes in mind). I'm not sure if there are many users who put oldstable and stable during an dist-upgrade in their sources.list, but these are also affected by this when a package they use changed its dependency during the last release cycle to include mta or APT::Install-Recommends is set to yes. > Ok, if the package in question also exists in stable, then installing > the oldstable version means the package will be immediately > out-of-date and it will have to be upgraded on the next apt-get run. I think in this case apt would directly install the exim package in stable, i.e. a transitional package (which does not exist for exim). > It does somewhat complicate the dependency graph to have a package > with numerous reverse-deps adding an or'ed dependency; this could > cause some pain to tools that process package dependencies (not just > apt - I'm specifically thinking of britney here), using a virtual > package and ignoring this case. But that's just speculation at this > point. I have no idea whether britney would handle virtual or real default-mta packages in a better way, ftpmaster should be able to answer this if it really matters. Deborphan for example currently handles virtual packages in a suboptimal way (although no false positives are caused by them) but this can be fixed. Maybe one could think about a release goal "handle virtual packages in a sane way"? Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
On Sun, Mar 01, 2009 at 08:25:38PM +0100, Carsten Hey wrote: > ... if apt would try to solve a dependency on the virtual package > default-mta provided by exim4 and exim5 it would ... choose to install > exim4 in the described case ... In case of a virtual default-mta package, the existence of a transitional package (exim did not have one in Etch) could prevent a package from an older release to be installed, but it would still use an old default and thus install a package that might be removed during the next release cycle. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
On Sun, Mar 01, 2009 at 04:55:23PM +0100, Andreas Metzler wrote: > We could have a exim4 upload implementing in sid this rather quickly > after receiving a go. In general I much prefer a virtual package over a real one but I think we should wait a bit until the following issues are clarified: On Fri, Feb 27, 2009 at 09:46:15AM +0100, Giacomo A. Catenazzi wrote: > [1] policy 7.5 has only a note: > | If you want to specify which of a set of real packages should be the > | default to satisfy a particular dependency on a virtual package, you > | should list the real package as an alternative before the virtual > | one. In my opinion it is a way better practise to first update the policy and then adapt n packages instead of first change them in a way which is possibly against the policy and expect the policy to be updated accordingly. RFC 2119 says: | 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there | may exist valid reasons in particular circumstances to ignore | a particular item, but the full implications must be understood and | carefully weighed before choosing a different course. The policy uses "should" in this case, do we understand the full implications of the proposed step carefully weighed before choosing a different course? We are probably on a good way to do this but until now at least I do not fully understand how apt and aptitude would handle all proposed solutions and what all possible negative side effects are. Among the problems we try to deal with the proposed solutions is, as Daniel wrote in <494422e7.2060...@debian.org>, that apt (and/or aptitude) take the alphabetically first package which provides foo and installs that to fulfill the relation to the virtual package foo. Knowing this leads to an possible answer to the following question: On Fri, Feb 27, 2009 at 11:03:20AM -0800, Steve Langasek wrote: > On Fri, Feb 27, 2009 at 10:37:19AM +0100, Adam Borowski wrote: > > Assume that in squeeze, the default changes to exim5. With an > > actual pseudopackage, someone having both lenny and squeeze (or > > unstable) in apt's sources will have default-mta either from lenny > > (->exim4) or from squeeze (->exim5). > > > > With mere "provides:" (a virtual package), you'd have a version of > > both exim4 and exim5 that provides default-mta. > > And what problem do you believe the latter will cause, in practice? I hope I'm wrong, but I think if apt would try to solve a dependency on the virtual package default-mta provided by exim4 and exim5 it would, according to Daniel's explanation and my own experience, choose to install exim4 in the described case since it is the alphabetically first package *1. On one of my stable desktops I still have oldstable in the sources.list because I tried to isolate a bug using some packages from oldstable, both oldstable and stable are pinned to 500. I obviously don't want to install a mta from oldstable. A default-mta package would to the right thing and install the mta from stable instead of the one from oldstable since real packages work with pinning and have a version number which ensures that the newest version of two equal-pinned packages with the same name is installed. There has been an argument that a real default-mta package would be suboptimal because this would be equally to what we have now with gcc, which leads to new packages (gcc-X.Y or eximZ) to be installed. This is in my opinion wrong as gcc and its dependencies are completely different to what has been proposed for the default-mta package. If you install a default-mta package which depends on "exim4|mta" (I hope that has been proposed, if not it should have been) and exim4 and then you upgrade your default-mta package which now depends on "exim5|mta", the fact that exim4 provides mta ensures that the dependencies of the new default-mta package are satisfied and apt/aptitude would not, unless this part is really messed up, try to install exim5. Using virtual packages for now and hope apt/aptitude handle virtual packages in a better way until exim5 will be the default mta could be one possible course, but what happens when they do not? Mixing virtual and real packages does not sound that good. Unless I'm wrong and the virtual packages support is a lot better than I think, it looks like main question is whether it is better to use a real default-mta package or wait for apt and aptitude to be improved. Regards Carsten *1 Or it uses the package from the first sources.list entry, I guess apt would rather do this when the virtual package can be found in more than one sources.list entry, but anyway, why apt might choose the wrong entry is not really important now. Important is that we are not sure that it would choose exim5 in this example. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Making some tags mandatory
On Sun, Mar 01, 2009 at 01:01:49PM +, Ben Hutchings wrote:
> On Sun, 2009-03-01 at 02:42 +0100, Carsten Hey wrote:
> > Deborphan needs a way to detect shared libraries ...
> [...]
>
> There is already a role::plugin which should apply to PAM modules.
role::plugin seems to fit. How do we ensure that all PAM, Apache, Roxen
modules, all DSPAM backends and so on must be tagged role::plugin? Is
there some kind of debtag policy where such things can be specified?
There are other possibilities to address this issue, either
section::{libs,oldlibs,perl,...} to store the old section or a special
tag that marks the package as safely removable, for example
sepecial::safely-removable or the existing special::auto-inst-parts.
The latter is currently only partly useful for deborphan since only very
few libraries are marked with this tag:
$ grep-debtags -sPackage -FTag special::auto-inst-parts | grep '^Package:
lib' | grep -vEc 'common$|data$'
17
Are there any plans to either tag all safely removable shared libraries
with special::auto-inst-parts or remove this tag from the ones that
already got it?
I guess all tags will be included in /var/lib/dpkg/status before
sections will be removed from Debian, is this correct?
Carsten
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive (deborphan)
On Sun, Mar 01, 2009 at 10:14:34AM +0100, Bernhard R. Link wrote:
> * Carsten Hey [090228 19:21]:
> > > It shouldn't be anything harder than adding 'deprecated'
> > > (non-library, deprecated software) to complement oldlibs,
> >
> > Adding non-library packages to oldlibs would cause these to be
> > handled like a library by deborphan and thus possibly being falsely
> > displayed as orphaned libraries. Since people tend to run aptitude
> > purge `deborphan` in loops [1] or use similar constructs I saw in
> > the past this would lead to unintended package removals.
>
> I think the "unintended package removal" depends mostly on what is
> actually put in oldlibs or a new deprecated section.
Yes, exactly. What will be in the deprecated section is not that
important since deborphan can be accordingly adapted and until this is
done no package from this section is detected as orphan per default.
> There have been non-library packages in oldlibs, for example
> shellutils and other transitional packages.
Transitional or dummy packages that are removed will not cause a RC bug
but they are no libraries and thus actually do not belong to oldlibs.
There is as far as I know no official description of what packages
belong to which section so we should use the obvious definition implied
by the name of the sections.
> For those deborphans behaviour of removing the package once no longer
> something depends on them was exactly the right thing.
In case of fileutils, textutils and shellutils one justification to move
them to oldlibs was that deborphan would list them by default, this may
be appropriate in carefully selected cases.
> Thus I think the issue are not non-library packages, but packages that
> supply user-visible functionality.
There is no issue at all unless packages which should not be listed are
(temporary) moved to oldlibs, which nobody planned. Enrico only
suggested to put them directly to deprecated and then move the packages
from oldlibs to deprecated, which would be ok.
I only did mention what would happen if this is done in an other
sequence to ensure that everybody involved in the upcoming section
changes is aware of this possible serious consequences.
> If the new deprecated section would have the requirement that packages
> to be put there should not cause significant[1] user visible changes,
> then everything would be ok.
With these requirements deprecated could really be handled like oldlibs
but until now I did not have the impression that this is planned. This
would also imply that no old, rarely used and unsupported mail user
agent or web server could be part of deprecated at any time, actually no
package including a file in {/usr,}/{s,}bin.
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Making some tags mandatory
Deborphan needs a way to detect shared libraries like the ones currently in section libs and distinguish them from packages which are technically shared libraries but can not assumed to be orphaned when no other package depends on them. The obvious examples for such packages are modules (role::module?), e.g. those used by pam, apache or roxen. Examples for less known module (or is role::backend better in this case?) packages include libdspam7-drv-*. I'm not sure if there are other, non-module shared library packages that can not be removed safely. Someone who knows how to use tags should be able to go through a list of packages which are not in section libs or oldlibs and tagged role::shared-lib to find out whether additional tags might be needed or if the remaining packages are just placed in the wrong section. On Fri, Feb 27, 2009 at 11:48:30AM +, Enrico Zini wrote: > role::shared-lib - Shared Library This tag alone is not sufficient: $ apt-cache show libapache2-mod-mono | grep -o role::shared-lib role::shared-lib $ apt-cache show libpam-runtime | grep -o role::shared-lib role::shared-lib Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive (deborphan)
On Sat, Feb 28, 2009 at 01:03:39PM +0100, Enrico Zini wrote: > On Fri, Feb 27, 2009 at 10:03:55PM -0800, Steve Langasek wrote: > > There are tools that understand the special meaning of the 'oldlibs' > > section and treat it specially; at least deborphan comes to mind, > > there may be others. I don't see the necessity for such a section > > rename, Actually he also talks about adding deprecated non-library packages, so this is more than just a "section rename". > > but if it happens I think it needs to be announced in advance and > > coordinated. Per default deborphan assumes that libraries are in libs or oldlibs. This is necessary to find orphaned libraries but prevent packages like libpam* or libapache* to be displayed as orphans. The upcoming section changes will break this assumption and thus there will be many false negatives (orphaned libraries that are not found anymore) until large parts of deborphan have been adapted or rewritten. In comparison to the other proposed changes the removal of oldlibs is only a minor issue for deborphan. With my deborphan upstream/maintainer hat on: Given that no non-library packages will be added to oldlibs, and this change happens at the same time as the other section changes, the removal of oldlibs is ok for me and I do not feel the need to further coordinate this. Additionally no non-library packages must be added to libs or libdevel at any time, I guess nobody had such plans anyway. > It shouldn't be anything harder than adding 'deprecated' > (non-library, deprecated software) to complement oldlibs, Adding non-library packages to oldlibs would cause these to be handled like a library by deborphan and thus possibly being falsely displayed as orphaned libraries. Since people tend to run aptitude purge `deborphan` in loops [1] or use similar constructs I saw in the past this would lead to unintended package removals. > ask tools to treat them equally, The two sections are not exactly equal and handling them equal would be wrong (see above). > and when we're satisfied that they do, just get rid of oldlibs. No, deborphan will be adapted after all section related changes in the archive are done. Ad interim, conservative defaults and algorithms in deborphan ensure that additional or missing sections do not cause false positives. Deborphan will support both section layouts until the next change related to sections happens, at least unless the new section layout will be messed up in a, from the viewpoint of deborphan, non-backwards compatible way. Regards Carsten [1] http://debaday.debian.net/2007/10/21/deborphan-find-packages-you-dont-want/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Hosting the Debian/kCygwin port?
[removing cyg...@cygwin.org] On Wed, Jan 21, 2009 at 11:14:24AM +0100, Samuel Thibault wrote: > So maybe debian-win32 could just be awaken since the barring issue > seems gone? This is what I would try first. I hope you are successful with this. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Hosting the Debian/kCygwin port?
Sjors Gielen wrote: > ... but the Cygwin packages are different from their Debian > counterparts (think patches), and I'm not sure how that happens with > other ports. debian-devel, is this a problem? No, this is no problem. Debian GNU/kFreeBSD also uses additional patches. Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Hosting the Debian/kCygwin port?
Hi. Sjors Gielen wrote: > Now I'm wondering where to host this project. I've been thinking about > three locations: Sourceforge, Debian or Cygwin. I've filed a project > takeover request for Sourceforge, but the original project admin seems > to work against me a little and it doesn't seem "fit" to release > there. debian-cygwin.sf.net is a Debian GNU/w32 port and I see no reason to remove the project page on Sourceforge. Although there are no releases, there has been some work done (see http://lists.debian.org/debian-win32/) and this site should IMHO at least reside for historical reasons. Maybe there is a chance to reanimate this project or at least reuse some of the work that has been done or concepts that have been developed. You called your port Debian/kCygwin, so why don't you prefer debian-kcygwin instead of debian-cygwin as Sourceforge project name? The former is still available. A few comments about the name: - Debian GNU/kCygwin seems to fit better since you use a GNU userland and Debian people tend to share the FSF view about naming operating systems. - The "k" means normally "kernel of". The idea is probably born because Debian GNU/FreeBSD was already taken by a port that used the libc from FreeBSD. Later IIRC Robert Milan had the idea to use the GNU libc for a Debian FreeBSD Port and only the kernel from FreeBSD. This makes porting single packages a lot easier but requires porting glibc first (the FreeBSD specific diff against glibc is IIRC about 1 MB). > Since the largest part of the project would be the packages in their > new Debian source and binary forms, I at least need an apt repository. > The Debian project already has the structure for that ... You can create the repository yourself using eg. reprepro until your port is more integrated into the Debian infrastructure. I don't think that you will get the permission to host your port on debian-ports.org and thus make this port semi-official before you prove that there has been a significant amount of work done since you are yet unknown among the Debian developers and currently no Debian developer is working with you on this. Debian operates an own Sourceforge clone but this is hosted on a single server with a relatively small harddisk, so this is not an option for hosting. I would first host it on Sourceforge using a not already taken project name and after you are able to show first results try to move it to debian-ports.org. Chances that it will be hosted on debian-ports.org and be integrated in the whole Debian infrastructure are way better when you are able to provide some working packages, at least "required", "important" and a subset of "standard" and "optional" (I think about things like perl and build-essential including its dependencies as a useful subset of "standard" and "optional"). The reasons for the relatively few responses to your mail are probably that most Debian people are not that interested in Windows in general and that you did not provide pointers to the work you have done until now. When you look at the subscriber count of debian-win32 you see that there are at least some people that are interested in such things (it has even more subscribers than debian-qa or debian-www). Such a big project is easier to do when you work together with other people, a more detailed mail with pointers to code and/or specifications to debian-wi...@lists.debian.org might be a good way to find those. I wish you much fun and success with your port Carsten -- Please CC me, I don't read this list regularly. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can a package modify slapd.conf in its maintainer script?
On Sun, Aug 10, 2008 at 08:53:32PM +0200, Carsten Hey wrote: > But the whole procedure is valid since it is only a recommendation by > the policy, so this is IMHO not a release critical bug. If the consensus on this will be that this bug is RC then there is also a bug in the policy and the wording should be changed (s/should/must/). Carsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can a package modify slapd.conf in its maintainer script?
RFC 2119 says: | 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there |may exist valid reasons in particular circumstances to ignore |a particular item, but the full implications must be understood and |carefully weighed before choosing a different course. Debian Policy Manual says (quoting an old version, since the enumeration makes the original intension more clear): | 11.7.4 Sharing configuration files | | ... | | The maintainer scripts must not alter a conffile of any package, | including the one the scripts belong to. It is not a conffile, so this is not a problem. | ... | | If it is desirable for two or more related packages to share | a configuration file and for all of the related packages to be able to | modify that configuration file, then the following should be done: | | 1. One of the related packages (the "owning" package) will manage | the configuration file with maintainer scripts as described in the | previous section. | 2. The owning package should also provide a program that the | other packages may use to modify the configuration file. | 3. The related packages must use the provided program to | make any desired modifications to the configuration | file. They should either depend on the core package to | guarantee that the configuration modifier program is | available or accept gracefully that they cannot modify | the configuration file if it is not. (This is in | addition to the fact that the configuration file may | not even be present in the latter scenario.) The whole procedure *should* be done, so this is not a must. Is there a valid reason in this particular circumstance to ignore the recommendation of the policy? Do you unterstand the full implications and did you carefully weighed your decision to alter the other packages configuration file (see quoted part of the RFC)? Is the other packages maintainer aware of the changes you do in his or her configuration file? I think such circumstances should at least be documented and would prefer to not alter the configuration file at all or using such a modifying script, so yes it is a bug and can't simply be closed. But the whole procedure is valid since it is only a recommendation by the policy, so this is IMHO not a release critical bug. Regards, Carsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
