Re: Being part of a community and behaving
> "Cameron" == Cameron Norman writes: Cameron> Apparently this is a known issue, and another person has experienced Cameron> it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426 >> >> That and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769499 are >> closely related, and will be fixed in the next syslog-ng upload (likely >> early next week). I know how to fix both, but lacked the time to >> implement said fixes so far. Cameron> This is a great chance to use the 'newcomer' tag recently added as an Cameron> official tag. It is for relatively simple bugs that a fix is known Cameron> for, but the maintainer just does not have the time. Please do Cameron> consider it in the future! Sadly, no, it's not a great chance. The problem is not all that simple, and sadly explaining in sufficient detail what the issue is (so that it can be fixed by a newcomer) is more time and effort than fixing the bug itself. But I do know about the tag, and will use it for other issues, when it is fitting. -- |8] signature.asc Description: PGP signature
Re: Being part of a community and behaving
> "Cameron" == Cameron Norman writes: >>> OK, so the system has syslog-ng installed. For what ever reason >>> syslog-ng >>> is not starting automatically, but starts manually by systemctl. >> >>> syslog-ng version 3.5.6-2 >>> systemd version 215-5+b1 >> >> Maybe some failure to sync status correctly? syslog-ng does ship >> with a >> service file. What does: >> >> systemctl status syslog-ng >> >> say? Particularly the Loaded and Active fields should have some >> hint as >> to what's going on that's preventing the service from starting >> automatically. Cameron> Apparently this is a known issue, and another person has experienced Cameron> it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426 That and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769499 are closely related, and will be fixed in the next syslog-ng upload (likely early next week). I know how to fix both, but lacked the time to implement said fixes so far. -- |8] signature.asc Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
>>>>> "Raphael" == Raphael Hertzog writes: Raphael> Hi Gergely, Raphael> On Wed, 12 Nov 2014, Gergely Nagy wrote: Raphael> When releasing a Debian package, the packager should create and push Raphael> a signed tag named `/`. For example, a Debian maintainer Raphael> releasing a package with version 2:1.2~rc1-1 would create a tag named Raphael> `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with Raphael> version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should Raphael> point to the exact commit that was used to build the corresponding upload. >> >> Mmm... I disagree here too. I think following upstream tagging >> conventions would be the way to go here. So if upstream uses >> `-` tags, then debian releases would be tagged like >> `debian/foo-2%1.2_rc1-1`, if upstream is `foo-1.2rc1`. Raphael> And if upstream uses v1.2.3 we should use debian/v1.2.3-1? Yes. Raphael> Do you know many upstreams using "foo-1.2.3" as tags? syslog-ng and syslog-ng-incubator uses foo-1.2.3, so does a few of my own (libmongo-client, riemann-c-client), and I came across a few others, but I haven't been keeping track. Raphael> I must say that I don't see the value that this brings. It might be Raphael> aestethically more pleasant when browsing the list of tags but for Raphael> everything else, it's just more painful. We lose the ability to Raphael> easily identify the commit of a given Debian release (instead Raphael> of a simple lookup operation, you have to scan all existing tags, and even Raphael> then if you have no clear mapping with the Debian version, you can't be Raphael> sure that you will find the correct tag). It's just two lookups, but I see your point. Sticking to the more common v$VERSION as a recommendation is good enough. >> I'd like to note that there are very good reasons for a debian-only, >> overlay-style packaging repository too. This section should, in my >> opinion, at least acknowledge that, and briefly mention it as an option. >> I find it a bit sad that it was outright discouraged. Raphael> I'm open to that, but IMO the only case where there are very good reasons Raphael> are the case where the upstream data is really huge and not easily Raphael> patchable anyway (i.e. the case of openarena-data that Simon Mc Vittie Raphael> described in https://lists.debian.org/debian-devel/2014/08/msg00582.html). Raphael> Are there other reasons that you consider good enough to impose the above Raphael> penalties on other possible contributors (i.e. making it impossible to use Raphael> gbp pq or similar tools to update debian/patches)? My reason for going debian-only is that I'm doing far more packaging work, than upstream. I hardly ever touch upstream, to be honest. But I actively maintain half a dozen packaging branches, and do merges between them. This would be a big headache if upstream sources were there, because some of these branches belong to different upstream versions. >> For the record, I used to hate that style, and was an advocate for >> storing upstream sources in the repo too. Then I started maintaining ~6 >> packaging branches: three upstream versions, two packaging branch >> variants of each. The overlay style proved to be far superior in this >> case. Raphael> Can you elaborate on how it was superior? See the use-case above. It was superior because I could do merges much easier, my history looks nicer, and upstream can use my debian-only repo as an overlay too, to build their own unofficial packages. It's very useful not only for the case when you have numerous active packaging branches, but in the case when you work with upstream on unofficial packages, too. With an overlay, they can just include it as a submodule, or use git-buildpackage with its overlay support, on top of pretty much any codebase they want, with minimal modifications. Raphael> I have put this for now: Raphael> @@ -195,6 +203,12 @@ choice to update the debian/patches quilt series: multiple helper tools Raphael> need the upstream sources in Git to manage this patch series as a Git Raphael> branch. Raphael> +When you have good reasons to only store the `debian` packaging directory Raphael> +(for example when the uptream sources are really huge and contains mostly Raphael> +non-patchable data), you can do so but you should then document Raphael> +this in `debian/README.source` along with some explanations of the tool Raphael> +to use to build the package. Raphael> + Raphael> Managing debian/changelog Raphael> - Raphael> Does that sound better? Better, but this still leaves it as a second-class citizen, with which I'm not entirely happy with. -- |8] signature.asc Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
> "Jonathan" == Jonathan Dowland writes: Jonathan> On Wed, Nov 12, 2014 at 03:38:59PM +0800, Paul Wise wrote: >> Personally I wouldn't use anything other than debian-only repos, at >> least for those where I have a choice. I also actively avoid >> contributing to packages that don't use such repos. Jonathan> And I'm the exact opposite. Which is fine - both layouts have their pros and cons and use cases. There are some cases where I prefer upstream+debian in the same repo, too. Hence, providing both as options, without a clear recommendation of one of them, in DEP-14 would benefit us all, in my opinion. -- |8] signature.asc Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
> "Raphael" == Raphael Hertzog writes: Raphael> Packaging branches and tags Raphael> === [...] Raphael> The Git repository listed in debian/control's `Vcs-Git` field should Raphael> usually have its HEAD point to the branch corresponding to the Raphael> distribution where new upstream versions are usually sent. For Debian, Raphael> it will usually be `debian/sid` (or sometimes `debian/experimental`). Raphael> QUESTION: some people have argued to use debian/master as the latest Raphael> packaging targets sometimes sid and sometimes experimental. Should we Raphael> standardize on this? Or should we explicitly allow this as an alternative? I'd suggest not standardizing on this, but having a list of recommendations instead, without naming one single name as THE recommended one. For different use cases, different HEAD makes sense. Also, I like to name my branches according to the distribution that it will target, which means I prefer debian/unstable over debian/sid. For me, that makes more sense, at least in the case of unstable and experimental. For anything else, codenames it is. Raphael> When releasing a Debian package, the packager should create and push Raphael> a signed tag named `/`. For example, a Debian maintainer Raphael> releasing a package with version 2:1.2~rc1-1 would create a tag named Raphael> `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with Raphael> version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should Raphael> point to the exact commit that was used to build the corresponding upload. Mmm... I disagree here too. I think following upstream tagging conventions would be the way to go here. So if upstream uses `-` tags, then debian releases would be tagged like `debian/foo-2%1.2_rc1-1`, if upstream is `foo-1.2rc1`. Raphael> Other recommendations Raphael> = [...] Raphael> What to store in the Git repository Raphael> --- Raphael> It is recommended that the packaging branches contain both the upstream Raphael> sources and the Debian packaging. Users who have cloned the repository Raphael> should be able to run `dpkg-buildpackage -b -us -uc` without doing Raphael> anything else (assuming they have the required build dependencies). Raphael> It is also important so that contributors are able to use the tool of their Raphael> choice to update the debian/patches quilt series: multiple helper tools Raphael> need the upstream sources in Git to manage this patch series as a Git Raphael> branch. I'd like to note that there are very good reasons for a debian-only, overlay-style packaging repository too. This section should, in my opinion, at least acknowledge that, and briefly mention it as an option. I find it a bit sad that it was outright discouraged. For the record, I used to hate that style, and was an advocate for storing upstream sources in the repo too. Then I started maintaining ~6 packaging branches: three upstream versions, two packaging branch variants of each. The overlay style proved to be far superior in this case. In short, I'd suggest having the DEP document both layouts, and recommend using one of them, while also recommending to document it in debian/README.source. -- |8] signature.asc Description: PGP signature
Re: Let's abandon debian-devel.
>>>>> "David" == David L Craig writes: David> On 14Nov10:2154+0100, Gergely Nagy wrote: >> You do realize topic lists are public too, right? David> Yes, but most Debian users don't even know about David> them nor do they need to since the traditional David> lists have been doing their jobs for quite a David> while. If you shut them down, I expect most of David> the public will not find the topic lists. Most Debian users need not concern themselves with development lists, like they usually do not subscribe to debian-devel@ either. If they do want to find a list for a particular topic, it is not rocket science to do so. They will find it. -- |8] signature.asc Description: PGP signature
Re: Let's abandon debian-devel.
> "David" == David L Craig writes: David> On 14Nov10:2325+0900, Charles Plessy wrote: >> With most of the work done on topic mailing lists, trolls lose the lever effect >> they have when feasting on debian-devel or debian-vote. Let's make our project >> stronger by reducing thr attack surface for troublemakers. David> But weaker by becoming more non-public? At what point David> is the Social Contract undermined? What about transforming David> those lists into readable by all but open only to David> certain responsible posters instead? You do realize topic lists are public too, right? -- |8] signature.asc Description: PGP signature
Re: Seeking help with OpenVPN scripts and systemd
Daniel Dickinson writes: > On 10/09/14 02:52 PM, Noel Torres wrote: >> >> Yes. Why to install OpenVPN which might not work? aptitude will tell you >> that >> they are not coinstallable and the sysadmin will then have the option of >> switching init system to a non default one, knowing what that means, and >> having a working OpenVPN config, instead of (possibly) having a failing >> config >> and no clue about why. >> > +1 with the caveat that this is not a *solution* but a recognition of > the fact of the matter until the situation is resolved by the much > harder task of geting openvpn's config to work with systemd. OpenVPN works just fine with systemd. Its init script does not, but for quite a few use cases, that is not an issue: the package just comes disabled by default, where the admin has to do some local configuration. There is no problem with that, at all. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r3zicl37@balabit.hu
Bug#755887: ITP: adderall -- a miniKanren implementation in Hy
Package: wnpp Severity: wishlist Owner: Gergely Nagy * Package name: adderall Version : 0.1.2 Upstream Author : Gergely Nagy * URL : https://github.com/algernon/adderall * License : LGPL Programming Lang: Hy Description : a miniKanren implementation in Hy This is a dependency of Hydiomatic, a Hy code transformer. But it's useful in its own right too. I've yet to come up with a reasonable long description, though. The module will be packaged under the umbrella of pkg-hy, along with its dependency (monaxhyd) and Hydiomatic. Binary packages created will likely be called python-hy-adderall and python3-hy-adderall. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140724095920.19466.74391.reportbug@angthalion
Re: systemd-fsck?
Thibaut Paumard writes: > Le 15/05/2014 10:55, Gergely Nagy a écrit : >> You do realise we have one libc (sure, you can install *additional* >> ones, but we have one libc the archive is compiled against), we have one >> package manager (you can, of course, install rpm too, it is packaged!), >> we have one "make" we use to build packages (you can try with others, at >> your own peril, though), and we have one init system (you can install >> anything else packaged, of course), right? > > If I follow your logic: > > "We have one desktop environment (xfce). Sure you can run GNOME, at your > own peril." > > I'm not sure you wanted to reach this conclusion, but here it is. That is a perfectly fine conclusion. If I want something else than the default desktop, I'll make it work, and put in the effort (patches, if need be) to make sure it is smooth for my use case. If there are others who prefer an alternative too, and make it so that I don't have to do anything at all, just an apt-get install gnome, so much the better! -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvkb9ved@balabit.hu
Re: systemd-fsck?
Thorsten Glaser writes: >>. This >>> is a perfectly fine job for a derivate or Pure Blend: to provide a >>> polished system that serves one use case well. >> >>Proper integration certainly belongs into Debian or did we become a >>supermarket: > > Proper integration of components: yes. That is the _job_ of a distro. > > Integration of some components at the cost of disabling the freedom > of users to choose a different free component that also does the job, > and at the cost of removing some users' use cases: no. That is not > the job of a "Univeral OS". So-called Enterprise distributions can > do that, sure. Downstreams and pure blends, too. But not Debian. You do realise we have one libc (sure, you can install *additional* ones, but we have one libc the archive is compiled against), we have one package manager (you can, of course, install rpm too, it is packaged!), we have one "make" we use to build packages (you can try with others, at your own peril, though), and we have one init system (you can install anything else packaged, of course), right? We have a default, that's what Debian is integrating to. You want to change the default, that's what downstreams are for. You have the freedom to change whichever component you want, if you find people to do the neccessary work. Trying to support N+1 options and integrating them *all* places a huge burden on every single maintainer, a burden you do not want, nor need. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87sioba09u@balabit.hu
Re: Debian default desktop environment
Russ Allbery writes: > Sune Vuorela writes: > >> Part of me wants to have KDE Plasma Desktop as the default workspace, >> because it is completely awesome. > >> Other parts of me is happy that it is not the default because then we >> don't have all sorts of weird wishes about "oh noes. networkmanager" or >> "Please use this non-integrated piece of messaging software because it >> does something that no one uses". > > We should change the default desktop environment with each release so that > each maintenance team gets to share in the fun! It's like a giant hazing > ritual. :) Can we have ratpoison + selected things as default DE for Debian Zurg? Please? Pretty please? With sugar on top? -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ppktwlmk@balabit.hu
Re: default init on non-Linux platforms
Thomas Goirand writes: > Actually, thinking about it a 2nd time, I think there would be a major > drawback in delaying to Jessie +1. If we decide that sysv-rc goes away, > then starting at the Jessie release, we don't have to care anymore about > LSB header scripts. Meaning that we could write systemd service files, > plus OpenRC runscripts (for those who cares about OpenRC, or our > non-linux ports). > > If we delay it, this means that we'd have to keep maintaining LSB header > scripts in Sid for all the life of Jessie (for those who cares about > non-linux ports or having OpenRC / sysv-rc support). > > Thoughts anyone? >From a maintainer PoV, I already maintain sysvinit scripts for wheezy, and upstream, they will have to be maintained for the forseeable future anyway, so maintaining it for Jessie is exactly zero work on my part. Adding OpenRC to the mix (something I'm not familiar with, and I'm not really interested in getting to know better, either) is an extra burden I wouldn't want to do myself. I wouldn't say no to a patch adding an OpenRC runscript, of course, but I'd rather not do it myself. -- |8] P.S.: If you're curious, and would like to send OpenRC runscript patches, syslog-ng-core is the single package in the archive where I maintain a sysvinit script. ;) -- 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/877g8stjem.fsf@algernon.balabit
Re: Two line init.d scripts? Sure, that will work!
Matthias Urlichs writes: > Oh except that some people didn't, which causes problems for the systemd > transition -- because init skript that are not skeleton-based don't know > how to redirect itself to systemd … Err, no. I have plenty of sysvinit scripts that work just fine with systemd, and are not at all based on skeleton. > I'd much rather have something well-tested and upgradeable which takes the > five lines you actually need for the common case(!) from a working systemd > service file and produces a sensible init script from that. I'd much rather support one init system that works instead of trying to find workarounds for something that ended up being terrible. Even if you generate an init script from systemd service files, the end result will be terrible, on the same level as the current sysvinit situation is. There's a reason it has not been done neither for upstart, nor for systemd: it's not worth it. -- |8] -- 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/877g8tsqec.fsf@algernon.balabit
Re: Two line init.d scripts? Sure, that will work!
"Francesco P. Lovergine" writes: > On Thu, Feb 06, 2014 at 11:59:11AM +, Ian Jackson wrote: >> >> I think the best approach would probably be to automate the generation >> of init scripts in debhelper. >> > > Seconded. Using an auto-generated skeleton starting from a simple template > would be more than enough to solve the main problem i.e. simplify maintainer > life. No, it would be a terrible idea: First, to reliably support all of the init systems, you'd have to target the dumbest one, and either not support the features of the others, or emulate them to some extent within generated code. Not supporting features of modern init systems means that the generator is completely useless. Trying to emulate features of the other init systems means you'll have quite a bit of complexity and strange behaviour. That's not going to simplify anyone's life, quite the contrary: it will make debugging orders of magnitude harder, because you will now need to debug not only the init script and the software itself, but the generator too. No, thanks. If you want to properly support multiple init systems, write the init scripts / service files / etc for each of them. Anything else is going to cause more trouble than what it is worth. The effort spent on trying to come up with a way to generate init scripts from sources is better spent creating systemd/openrc init files for software that don't have it yet. If half the people campaigning for a generator would have written one init script or service file a week, we'd have most things covered by now. -- |8] -- 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/87eh31sxr1.fsf@algernon.balabit
Re: systemd2init PoC
Thomas Goirand writes: > What about exploring Ian Jackson's idea, which was to hack a debhelper > that would generate things for multiple init systems? Can I file RC bugs when that breaks horribly? (Because it will.) I would suggest not going down that route, it only leads to pain and suffering, much more so than maintaining multiple init scripts by hand, via patches over a 1200baud modem line, working from an ancient parisc box running hp-ux. (I tried, both.) -- |8] -- 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/87wqgxtyfj.fsf@algernon.balabit
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
The Wanderer writes: > Also because when writing a parser, it's easier to determine the format > (in terms of meaning and start/stop of each field) of a text file than > it is of a binary one, when working without known-reliable > documentation. (And I'm not willing to assume that I'll always have such > documentation.) Stop right there. You're so very wrong there, you cannot even imagine. Without documentation, you cannot assume *anything* about neither text nor binary. If you think you do, think again, you will be wrong. > There's a *reason* the vast majority of kernel userspace-interface files > are in plain-text form, after all. Interface? Yes. You give textual commands to journalctl, and it gives you text output back. Same way you echo something into files under /sys, or cat them, and something behind it *translates* that. The only difference is that journalctl is a user-space program, while the files under /sys are translated by the kernel. -- |8] -- 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/87wqh1sfqs.fsf@algernon.balabit
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
"Vitaliy Filippov" writes: >> Here's a challenge then: Implement everything the journal does, without >> using a binary format, and show us it's not only doable, but performs >> similarly. >> >> I would first recommend you read up - and try! - what the journal has to >> offer. It's not as simple as you make it out to be. > > Given that Debian transitions to systemd - it seems an option to me. ) > > But first I'll try to disable it completely, of course. IMHO it's also > a suitable solution. > > I understand there's more functionality than you can build up only > using regexes. The point is - I don't understand why an INIT SYSTEM > (!) should depend on these, generally non-trivial, features. I suggest you read the rationale behind the Journal, in particular the design docs: https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs (But, if you have comments about it, please take it upstream or keep it to yourself, in all honesty. We've been over this and other aspects of systemd many times.) -- |8] -- 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/871tz9tuod.fsf@algernon.balabit
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
vita...@yourcmc.ru writes: >> It is of course well-known that systemd developers like to make their >> life more complicated and love to implement binary formats instead of >> writing simple text parsers, just for the sake of having fun >> programming >> them, and absolutely not because they need things like indexing. >> >> The same goes for relational databases developers, for example. How >> silly of them all. > > 1) If you really need a binary index, it could be initially put in a > separate file. > 2) Binary index isn't needed at all if you just want to print output > of a service - you can just put output of each unit to its own log > file and just tail it. > 3) If you don't want to print only last X lines, but want to print > full output of a service since last start - you can remember the > previous log position in the service state structure. > 4) At a first glance I don't see any _real_ index (i.e. btree) > implementation in systemd journal, so I assume it still does fullscans > to print logs for a service - am I correct? > 5) After all, I don't see why writing 1 regexp is a hard task. And it > won't be really slower because of (4). Here's a challenge then: Implement everything the journal does, without using a binary format, and show us it's not only doable, but performs similarly. I would first recommend you read up - and try! - what the journal has to offer. It's not as simple as you make it out to be. -- |8] -- 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/87a9dxtxpf.fsf@algernon.balabit
Re: Two line init.d scripts? Sure, that will work!
Petter Reinholdtsen writes: > The reason I bring this up on debian-devel@ is twofold. First, I want > to gather feedback on the idea. Will it work for your package, or are > some more hooks needed? With my syslog-ng upstream hat on: please, for the love of $deity, no! It's bad enough having to care about three init systems on Linux, then some more on the BSDs, and not break legacy unixes either. With my syslog-ng debian maintainer hat on, I honestly do not want to deal with even more (and since I provide backports, I can't just abandon the old init script for the foreseeable future, either). Also, pushing complexity into a common script would only mean that if, for some reason, it needs a fix that only syslog-ng triggers, I'm screwed, and need to fall back to a full-blown script anyway. Having had a look at the current sysvinit file of syslog-ng, I'd fall back there anyway (mostly for the silly dance done in syslogng_wait()). The idea is nice in theory, but unless you go the full mile, and do a truly declarative syntax like systemd, from my point of view, it will be worthless. As a comparsion, here's the systemd unit file (15 lines including blanks): , | [Unit] | Description=System Logger Daemon | Documentation=man:syslog-ng(8) | | [Service] | Type=notify | Sockets=syslog.socket | ExecStart=/usr/sbin/syslog-ng -F | ExecReload=/bin/kill -HUP $MAINPID | StandardOutput=null | Restart=on-failure | | [Install] | WantedBy=multi-user.target | Alias=syslog.service ` Or the upstart service thingy (which I actually have never tried), which is 9 lines including blanks: , | description "system logging daemon" | | start on filesystem | stop on runlevel [06] | | expect fork | respawn | | exec syslog-ng --process-mode=background ` I assume an OpenRC init file would be similarly short. What would your solution buy me, that neither systemd, nor upstart do? Both which of those provide me features not present in sysvinit, which are tremendously useful for my use cases. -- |8] -- 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/87vbwsedus.fsf@algernon.balabit
Bug#730314: ITP: syslog-ng-incubator -- Extra modules for syslog-ng
Package: wnpp Severity: wishlist Owner: Gergely Nagy * Package name: syslog-ng-incubator Version : git master (or whatever I call it by the time I get there) Upstream Author : BalaBit IT Security Ltd. * URL : https://github.com/balabit/syslog-ng-incubator * License : GPL2+ Programming Lang: C Description : Extra modules for syslog-ng The syslog-ng module incubator is a collection of tools and modules for syslog-ng that for one reason or the other, are not part of the official repository. This serves both as a staging ground for experimental modules, and as a repository of plugins that are not aimed at upstream inclusion. It's also an example of a third party syslog-ng module. The package would contain the Riemann destination, a trigger-source for debugging, a couple of new template functions and various small utilities. The packaging is reasonably complete, needs some polishing, and riemann-c-client[1] to get through NEW. Maintenance will be under the umbrella of the syslog-ng maintainers[2]. [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728591 [2]: https://alioth.debian.org/projects/syslog-ng/ -- 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/20131123211348.9640.83907.reportbug@localhost
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Thorsten Glaser writes: > On Tue, 5 Nov 2013, Paul Tagliamonte wrote: > >> > First of all, I do not agree Debian community is hurt because of >> > split about init system, >> >> I disagree strongly. Please read through every flame thread over the >> last 4 years and try to say this with a straight face. > > That’s why I say let’s just support them all. Please no. That's a maintenance nightmare. I'm fine with one on GNU/Linux, another everywhere else (but I'll treat everything else as secondary), but supporting all of them, everywhere they're available, is madness. > Do remember that this is not about the (freeness of the) software but > of the users. > > http://mako.cc/copyrighteous/freedom-for-users-not-for-software > > Hence why I insist on freedom of choice, even though I’d never choose > systemd for myself, since I see that others would want it. Freedom of choice remains even when there's a default. We have a default desktop, default syslogd, default MTA, default-this, default-that, yet, we have alternatives for all of those. We have a default init now, and alternatives to that too. If we choose a different default, the alternatives can still co-exist, like they do now. Freedom is not lost. >> One of those freedoms is to use the software commercially, just FYI. > > I think that’s not his point. I read Marko’s mail as an argument against > vendor lock-in, and, let’s face it, systemd is company-backed (RedHat, > mostly), systemd is company-backed only as much as glibc or GNOME is. >> We shall not stand in the way of progress. logind, systemd (such as >> socket based activation, dependency booting) in particular, and friends >> are technical wins. We'd be silly to not take them. > > NO! We’d be silly to take them, because they lead to vendor lock-in, > and *especially* the systemd side has shown, time and time again, that > they won’t stop there. They intend to wholly change the ecosystem, to > get away from Unix and GNU and towards this thing some people now call > “FLOS” (one ‘s’). And change is bad, because...? I'm not sure about you, but I prefer to improve my systems instead of holding them hostage to ancient technologies, just because there's only one implementation of a particular solution. > But sometimes, they do – an æroplane is the perfect tool to transport > several dozen people from Europe to the Americas, for example (other > than a ship). Which is another reason for us to actively support both > sysvinit and one of the newcomers (such as upstart, since it’s much > less hostile). This way, people (actual users!) can choose. It’s not > necessary to install the whole systemd stack on a small one-purpose > VM, for example. Or on a tightly secured, small VM _host_ (when the > guests have all the power). This is a misguided reasoning. Just because we select *one* default, does not mean that all alternatives will be dropped. We have systemd and upstart in Debian, they're usable, yet, sysvinit is the default. Switching to systemd/upstart/OpenRC will not mean the rest will be dropped. The choice will remain. >> "without deviation from the norm progress is not possible" >> -- Frank Zappa > > Without competition, progress is not possible either. A systemd > monoculture – which clearly is what “the systemd/GNOME crowd” (they > really mesh together) want – will not help anyone. See above. -- |8] -- 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/87k3glvemn.fsf@algernon.balabit
Bug#728591: ITP: riemann-c-client -- C language client library for the Riemann event stream processor
Package: wnpp Severity: wishlist Owner: Gergely Nagy * Package name: riemann-c-client Version : 1.0.1 Upstream Author : Gergely Nagy * URL : https://github.com/algernon/riemann-c-client/ * License : LGPL-3+ Programming Lang: C Description : C language client library for the Riemann event stream processor Riemann is a network event stream processor, intended for analyitics, metrics and alerting; and to glue various monitoring systems together. . This library provides a C language client, with a simple but convenient API, to connect to Riemann, send events and run queries against it. I already have the debianisation complete, it just needs to be uploaded. This is a dependency of the syslog-ng-incubator project which I also plan to upload shortly after syslog-ng 3.5 made it into unstable. -- 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/20131103123707.10083.562.reportbug@localhost
Re: Nitpicking in the NEW queue.
Raphael Hertzog writes: > On Tue, 03 Sep 2013, Luca Falavigna wrote: >> 2013/9/3 Paul Wise : >> > Reading Charles' mail I had a thought; how about accepting buggy >> > packages (unless the issues make them non-distributable) and file RC >> > and other bugs if there are DFSG or other issues? >> >> Although this could be possible, a second upload would be needed >> anyway (hopefully in a very short timeframe), so reuploading a fixed >> package to NEW would avoid wasting bandwith and disk space on mirrors >> and snapshot.d.o. >> >> Usually, rejected packages are fast-tracked when reuploaded to avoid >> letting them slip at the bottom of the queue. Simply reply to >> rejection mail (or ping us in IRC) informing us a fixed package has >> been reuploaded to the NEW queue. > > This is not a good trade off. You're loosing out valuable ftpmasters time > for minor bandwith and disk issues (that kind of supplementary upload will > not change much in the global amount of bandwith and disk consumed). > > I find pabs's idea rather good. And if you really care about a second check, > you can do that once you get the bug closure notification. I disagree. A second review by the same ftpmaster is usually fast and painless and requires less time and effort overall than doing the bug handling dance. I've done both, and my experience so far was that REJECT+reupload worked much better in most cases. That it also keeps the archive a tinsy bit cleaner is just an added bonus. -- |8] -- 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/87hae20w2u.fsf@algernon.balabit
Re: DSA, kFreeBSD, and the Singularity
Peter Palfrader writes: > On Sun, 01 Sep 2013, Steven Chamberlain wrote: > >> I can only recall one wishlist bug from DSA at the moment which is >> #711247 requesting pflogd. I'd love to hear more wishlist kfreebsd >> ideas from DSA. > > syslog-ng on kfreebsd doesn't properly reconnect to logservers after > they went a way for a while or the network dropped. > > Would be nice if that could be fixed. I'd be happy to fix, if there's a bug filed (if there is one, and I didn't notice, apologies!). The problem should be fixed in later upstream versions, but I have not had the chance to test it yet, and we need to upload something more recent anyway. This will happen Real Soon Now(tm). But if there's a bug filed, I can likely find and backport the fix to wheezy too. (or provide a backport of the new syslog-ng upstream version on backports.d.o) -- |8] -- 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/87li3f1gqj.fsf@algernon.balabit
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Josselin Mouette writes: > Le lundi 22 juillet 2013 à 10:45 +0200, Gergely Nagy a écrit : >> systemd being installed does not mean it will be used as init. The >> package happens to contain a few tools the GNOME Shell needs, that is >> all, to the best of my knowledge. It's a harmless dependency if you >> don't use systemd, one that is only "scary" on paper. > > If you don’t use systemd, logind will be non-functional, and you lose > all features that require the system to know who is logged on what. Such > as shutting down the system, mounting USB devices, and so on. Ah, I didn't know that. That does sound considerably scarier than I thought. (Mind you, I am using systemd.) Thanks for the clarification! -- |8] -- 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/87ehaqnbai.fsf@algernon.balabit
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Vincent Cheng writes: > On Fri, Jul 19, 2013 at 9:35 AM, John Paul Adrian Glaubitz > wrote: >> On 07/19/2013 06:12 PM, Mathieu Parent wrote: >>> >>> As the recommended way to install systemd is using init= and not >>> installing systemd-sysv, maybe the popcon "vote" count is the correct >>> metric? >> >> >> Plus, systemd isn't pulled in by anything else which means when it's >> there it's there because it was actively installed. I don't think it >> magically lands onto a user's hard disk or someone installs it just >> in order to not use it actually. > > On the contrary, in experimental, gnome-shell depends on > gnome-settings-daemon, which in turn depends on systemd. I wouldn't be > surprised if this is one of the reasons sid still has version 3.4 of > the shell, rather than the latest upstream version (3.8). > > If/when gnome-shell 3.8 hits unstable and systemd gets forced on end > users as well...I dare say that the general outcry here on > debian-devel would make the past network-manager related threads look > tame in comparison. I offer my deepest condolences to the gnome > maintainers in advance (I doubt that they're looking forward to > dealing with all this). systemd being installed does not mean it will be used as init. The package happens to contain a few tools the GNOME Shell needs, that is all, to the best of my knowledge. It's a harmless dependency if you don't use systemd, one that is only "scary" on paper. -- |8] -- 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/87ppubm199.fsf@algernon.balabit
Re: Survey answers part 3: systemd is not portable and what this means for our ports
John Paul Adrian Glaubitz writes: > On 07/18/2013 09:15 AM, Thomas Goirand wrote: >> >> http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems > >> "friendly upstream yes no NO YES" > > Really? You put something like this in a technical comparison chart? A friendly upstream *is* important in a comparsion chart. Working with an unfriendly, or even hostile upstream is not something you want to have in a core component of an operating system. (Though, the table is obviously biased, and in my experience, highly incorrect, but such is the nature of most comparsions) -- |8] -- 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/87d2qgnl5h.fsf@algernon.balabit
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Thomas Goirand writes: > If OpenRC goes up to the shape I expect, it will have a huge advantage > over systemd and Upstart: it will not be controversial, If it would not be controversial, we wouldn't have this conversation about whether it is worth it at all. Just saying. -- |8] -- 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/87mwpmq53a.fsf@algernon.balabit
Re: systemd .service file conversion
Marc Haber writes: > On Thu, 30 May 2013 11:46:51 +0300, Riku Voipio > wrote: >>By switching early we can affect how a piece of software will evolve. > > This is the case with software that has a cooperative upstream. > systemd's upstream is known not to be. I never quite understood why people seem to think systemd upstream is uncooperative (well, apart from the whole non-linux porting deal, where their stance is completely understandable too). My experience so far suggests otherwise: I've have had very fruitful interactions with them, multiple times, in person and over the wire aswell. >From the mailing list and IRC channel, I get the same impression I got when personally involved. -- |8] -- 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/87mwrc7kuf.fsf@algernon.balabit
Re: Debian systemd survey
Adam Borowski writes: > On Thu, May 23, 2013 at 09:55:41AM +0200, John Paul Adrian Glaubitz wrote: >> On 05/23/2013 06:56 AM, Thomas Goirand wrote: >> > "As you may know, systemd is developed by a large amount of >> contributors" >> >> How on earth does that contradict with the fact that 40%, i.e. >> the minority of all contributions are done by the original >> author. 40% still means that 60% of the code comes from other >> people and those are 145 contributors according to ohloh [1]. >> >> OpenRC has 19 [2], upstart has even only 7 [3] contributors. >> >> So, yeah, systemd is definitely the project which has the >> largest amount of contributors which was exactly my point. > > Did you include the stats for all projects systemd wants to replace as > well? FWIW, systemd does *not* want to replace your traditional syslog. Parts of it, yes, but not all of it. So counting those projects in would be a mistake. -- |8] -- 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/87fvxcbu9q.fsf@algernon.balabit
Re: Debian systemd survey
Steve Langasek writes: > On Thu, May 23, 2013 at 09:11:55AM +0200, Gergely Nagy wrote: > >> Also, post-raring, systemd is available in Ubuntu aswell, and in some >> cases, you can check for systemd at runtime, needing no modification to >> the package *at all*. > > What's available in Ubuntu are the systemd dbus services, the libraries, and > a little-known daemon called 'udev'. The systemd init is *not* in Ubuntu > and there are no plans to change that. Those are enough to cover quite a bit of software well enough to not need Ubuntu-specific patches. -- |8] -- 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/87k3mobugf.fsf@algernon.balabit
Re: Debian systemd survey
Lucas Nussbaum writes: > - there are 300+ upstart job files ready to be imported from Ubuntu FWIW, there are a similar (if not more) number of systemd service files we can look at and import from: Fedora, openSUSE, Arch and possibly a few others too. (This I find to be a great strength of systemd by the way: it is (or is becoming) the default on not only one, but multiple unrelated distributions.) -- |8] -- 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/87obc2b1t8.fsf@algernon.balabit
Re: Debian systemd survey
Thomas Goirand writes: > On 05/23/2013 01:45 AM, Josselin Mouette wrote: >> I understand it will be a pain for Ubuntu if Debian picks a different >> init system. I don’t think this is relevant for the discussion, though. > > It might be very relevant for many of us that our package works on > *both* Debian and Ubuntu (and other derivative, including those who > derive from Ubuntu, like for example Mint) without too much > modifications. Some of my packages already incorporate some upstart > script for that reason. As someone who packages software that has explicit systemd supporting bits and pieces, which needs to be turned off on Ubuntu (at least pre-raring Ubuntu), I'd like to note that doing this is *simple*. Ubuntu have been patching out the systemd support from the syslog-ng package anyway, doing the same myself for my own packaging was trivial. I needed to make two modifications: remove libsystemd-daemon-dev from build-depends, and not install the unit files. In the future, when there'll be a dh_* tool to do the latter, I will need to do even less. Also, post-raring, systemd is available in Ubuntu aswell, and in some cases, you can check for systemd at runtime, needing no modification to the package *at all*. -- |8] -- 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/87sj1eb26c.fsf@algernon.balabit
on binary logs (was: Re: /bin/sh)
"brian m. carlson" writes: >> I have no idea why people assume that a binary format means it can only >> be processed with a special, proprietary tool. Binary simply means what >> it means, binary and not text which means it's a more stream-lined and >> machine-readable format as opposed to a text format with no formatting >> at all. > > It means that it works completely differently from every existing Unix > log parser on the planet. syslog is hardly "no formatting at all". Please allow me to disagree. syslog *is* the very definition of no formatting at all. The single most interesting part of it, the message is free form text. Good luck making sense of that. There is no common or widely accepted way of writing syslog messages. There's the SDATA thing, but hardly anyone uses that, and that is primarily for additional info: the message itself is still free form chaos. >> And, when it comes to processing, binary data is actually *easier* to >> process. Everyone who has ever written a text parser themselves will >> agree. > > I have written several, and I still prefer plain text. I want to use > the same tools to parse my logs that I have used for years, like > logcheck. Text files is the Unix way. Except text files are bad when you want to search, index, classify or do anything more complicated than grep or $PAGER. How many of the log analytics / log browser things use text files? I know of none, and it is no wonder. Text files are awful when you need random access, fast. -- |8] -- 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/877gj0fvlz.fsf_-_@algernon.balabit
systemd & journal (was: Re: /bin/sh)
"brian m. carlson" writes: > On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: >> This is utter bullshit and you should already know it. Systemd is much >> more reliable as a whole than any other implementation. I have yet to >> see a use case where it is not better. > > It is not better if you don't want proprietary binary-format logs in > /var/log with no documented way to turn them off. Your logs still end up being forwarded to a traditional syslogd, so there's exactly nothing you loose. The binary logs are also non-persistent by default, they do not eat up space under /var/log unnecessarily. In return, you gain a lot of goodies even when you do not directly use the Journal in any way, such as being able to safely switch or upgrade syslogds, without risking the system becoming unresponsible when /dev/log fills up, and quite a few more. (FWIW, with my syslog-ng hacker hat on, I like the Journal even more than I do with my regular user hat on.) > For better or for worse, sysvinit provides a lot of modularity. systemd > provides none of that modularity, and there are a lot of things it does > that I'd rather disable (or better yet, uninstall) because they're just > wrong. When I've used upstart and sysvinit, I've never had > functionality that I wanted to disable and remove. You must be talking about a different systemd then. -- |8] -- 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/87bo8cfvyi.fsf_-_@algernon.balabit
Re: Upstream packaging
Clint Byrum writes: >> Also if people thought that distributions are unneeded, then the >> amount >> of them would reflect that, or start decreasing, which I'm not seeing. >> Distributions will exist as long as there's FLOSS, because by its >> decentralized nature, there's no single coordination point; people >> who are distraught by the amount of distributions or by their mere >> existence might probably only be able to find peace in closed-systems >> instead, with their centralized control points. >> > > Nobody is distraught. The problem statement was something like > "distributions lag upstreams, how can we solve this?" and I'm > suggesting that its kind of already solved with upstreams who use > their native packaging format (i.e., autotools, pypi for python, or > maven for java). Its just that Debian has such strong policies that we > are unable to consume said packaging, because the upstream packaging > is less expressive. So, we have to lag while we QA all of our > specialness. There's so much more to packaging and *maintaining* a debian package than wrapping whatever upstream has in a .deb, even if we apply very few (or none at all) changes during the process. Just because something uses autotools, it will not mean you can trivially package it, or upgrade from one version to the other. There are a million things that can - and sooner or later, will - break even if upstream only uses standard tools. A new dependency, a new configure option, changing defaults, and all kinds of incompatible changes make maintainance neccessary and far more effort than you seem to imply. Most of these are things upstream do not have to care about: they'll document it in an UPGRADING file or similar, and delegate the task to their users. A distribution will most likely wish to automate most of that in a straightforward and safe manner. >>> Where Debian's efforts should be focused is on things like license >>> verification and helping bug reports and fixes get to upstream. >> >> So basically, getting rid of most of the fun stuff and turning it into >> a lawyerish play-ground and support center... I'd venture to say, not >> the most attractive work for most people here if it was the only >> thing to be done, which we do because we think it's important non the >> less. >> > > I am suggesting that there are a lot of things that are much more fun > than conforming software to Debian policy. Wouter said it very well, that the Policy is not a goal, but a tool to achieve a goal: that of an integrated system. Making packages conform to policy is pointless, if it is not done to achieve the goal. Creating a well integrated system on the other hand *is* fun, and something that can't be delegated to upstream, or anywhere else but the distribution itself. > I'm also suggesting that these things don't need to happen in the > context of Debian. Where else? Upstreams should not be concerned about integrating their software into distributions. That's what package maintainers are for: they know the distribution better, they have the skills and resources to do the neccessary integration work, they know how their distribution handles upgrades, and so on and so forth. Upstreams should provide the tools and documentation to make integration possible and smooth, but that's where it should end. As an upstream, I do not wish to care about any single distribution. I'll provide ample documentation, scripts and whatever else they need, but I do not wish to play the integrator role. If I start to do that for one distribution (wit my upstream hat on), I'll have to do it for the rest too. No, thank you, that is as far from fun as it can ever be. -- |8] -- 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/87mwsm7pgx.fsf@algernon.balabit
Re: No native packages?
Ian Jackson writes:
> Gergely Nagy writes ("Re: No native packages?"):
>> There are two native packages I maintain, and I've yet to hear a good
>> reason for making either of them non-native. Making it harder and much
>> much more inconvenient for downstream distributions to modify them is a
>> *goal* in these cases: to make it harder to diverge from one
>> another.
>
> I haven't looked up to see what these packages are, but I worry that
> what you are doing here is undermining the freedom of our downstreams.
The two packages in question are dpatch and dh-exec, and yes, what I do
with them could be considered as undermining the freedom of
downstreams. However, in this two cases, I believe that is a good thing,
as in the long run, neither we nor downstream should want to deviate
from one an other.
Why? Because if downstream introduces something there, and start to rely
on it, while upstream the same thing does not get introduced, or does in
a different way, everything that builds on either, will fall apart, and
make it that much harder to work together.
> The ability of our users and downstreams to choose to modify the
> software we distribute is the core of their software freedom. As a
> project we should be making it easier, not harder, to produce modified
> derivatives.
I agree, but to a limit. But there are tools that should be patched as
little as possible, to preserve interoperability between distributions,
and both dpatch and dh-exec are such tools that when they diverge in
either down- or upstream, interoperability suffers. Want something
included? Get it in upstream first, so things won't break.
That is one of the reasons I kept both as native, and why I believe
there is no compelling reason to change that.
--
|8]
--
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/87y5ek1brv.fsf@algernon.balabit
Re: No native packages?
Roland Mas writes: > Gergely Nagy, 2013-01-28 09:44:18 +0100 : > > [...] > >> By harmful side effects, I mean two things: > [...] >> - Patches not separated > > Not quite true. You can still have debian/patches/* and apply them at > build-time (dpatch or quilt), even if they're not shipped in a separate > .diff.gz file. How many native packages do that? And how is that less inconvenient than simply having a non-native package? -- |8] -- 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/87mwvs47oj.fsf@algernon.balabit
Re: No native packages?
Wouter Verhelst writes: > On Mon, Jan 28, 2013 at 09:44:18AM +0100, Gergely Nagy wrote: >> Wouter Verhelst writes: >> >> > On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote: >> >> Dmitrijs Ledkovs wrote on his blog[0]: >> >> >> >> >Generally if software is useful in Debian Project it can be useful >> >> >for other debian-like and unlike projects. In particular native >> >> >packages do not offer the same patching flexibility as 3.0 >> >> >(quilt), thus forcing downstream distributions to inline modify >> >> >packages without DEP-3 headers. This hurts us, when trying to >> >> >merge useful stuff from derivatives back into Debian, as changes >> >> >are not split into individual patches. >> >> >> >> I would tend to agree that we have too many native packages, >> > >> > There can only be "too many" of anything if it is (or can be) harmful in >> > some way to have the thing in question. >> >> Perhaps not a convincing argument, but one of the main reasons I >> mightily dislike native packages for things that aren't Debian specific >> in any way, is because it sets a bad example. If you see native packages >> being abused for the sake of convenience, > > Doing something for the sake of convenience is not a bad thing. On the > contrary; inconvenience is (terribly) bad for motivation and > productivity. Doing something for the sake of convenience is not, in itself, a bad thing indeed. Even with native packages, if you know what you're doing, and you're careful, you're not doing any harm, either. However, that's you, with a ton of experience behind your back, and deep knowledge of Debian. Then someone comes along, looking for examples, and sees a growing number of native packages: "Oh hey, this is easy, I'll do this too!" And things go downhill from there. There *are* cases where native packages are inappropriate, and it is already a pain in the backside at times to convince people new to Debian that native packages do have unwelcome properties in certain cases. My belief is that Debian packages should not only be technically sound (which a lot of them already are), but should also set a good example for those who are looking for inspiration, for ideas. It is a bit more work for the packager, yes, but I've yet to see a case where the extra work would not be trivially scriptable to the point that one only needs to remember a command or two - which is, as far as I'm concerned, far below the annoying threshold. (I know counter examples must exist, but for the general case, I doubt that the debian-upstream split would be all that hard, not even in the long run.) >> it becomes that much easier to give in to temptation, and use native >> packaging even when it does have harmful side-effects. > > That's a recursive argument: You're trying to convince me that doing > something is bad simply because doing it may cause us to do it more. But > if I don't think that "doing it more" is a problem any more than doing > that something in the first place is, you've not actually convinced > me. Imagine gcc or the linux kernel being native packages then. >> By harmful side effects, I mean two things: >> >> - Awkward to NMU > > As I said in my previous mail, that's indeed a bug that should be > fixed. Easily fixable by making the package non-native. >> - Patches not separated > > That's not a bug; it can be a feature, and even when it's not it can be > argued that it's not a terrible issue. Packages should be in SCM, and > you should have some form of communication with people who package work > with your code. If you don't, you have a bigger problem than whether or > not you're using native packages. That's a terribly sweet idea, but in practice, it doesn't work. If it would, I'd be the happiest person on earth. First of all, not all downstreams use an SCM (shocking, I know), and not all of them keep them up to date, especially if their SCM is located elsewhere than upstream's. I've seen both NMUs and downstream packages which were supposed to be in SCM, but the SCM was out of date. I'd love to trust downstream SCMs, but experience shows that rarely works, and my most stable point is whatever they have in their archive - and that's the Debian source package. I'd love if downstream talked to me directly, and sometimes they do, sometimes their SCM is even up-to-date, but most of the time, we talk in patches (which is also good, but what patches they send me, and what is in their archive often differs, as some patches are
Re: No native packages?
Tollef Fog Heen writes: > ]] Gergely Nagy > >> No, not really. I don't really care what tools one uses, as long as the >> result is reasonably easy *and* reliable to work with. Since VCS can be >> stale, and quite often does not include neither NMUs, nor backports, >> that fails the reliable requirement. > > It sounds like you are arguing that we should just ship the the > repository in the source package, then. No chance of it ever getting > out of date, trivial to find the merge points and missing patches > between two packages and fits much better with a VCS-driven workflow. That would be useful, yes, but that's unrelated to a package being native or not. What I'm saying is, Debian source packages *must* be useful on their own aswell, for those corner cases where the VCS is not an appropriate place to turn to. (Provided there's a VCS at all, but that's another discussion again) -- |8] -- 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/871ud45obi.fsf@algernon.balabit
Re: No native packages?
Philip Hands writes: > Gergely Nagy writes: > ... >> We have tools that make it easy to create upstream tarballs from an SCM >> repo. Git has git archive, gitpkg and possibly other tools make it very >> easy to create upstream tarballs: so much so, that it means nothing more >> than tagging the repo properly. >> >> I've been using this for quite a while for some of my packages (ivykis, >> libmongo-client), and it doesn't need neither an upstream build system, >> nor much thought once it is set up. (And setup is fairly trivial too) > > So to summarise your argument appears to be that it sets a bad example > (which is only a valid criticism if you manage to show why it's a bad > idea in the first place) and that you don't like people not using all > the same tools you use. No, not really. I don't really care what tools one uses, as long as the result is reasonably easy *and* reliable to work with. Since VCS can be stale, and quite often does not include neither NMUs, nor backports, that fails the reliable requirement. Exceptions exist, and three cheers for them! Only if they weren't the exceptions... > If the person doing the packaging is the upstream, you're asking them to > pretend to be two people, and decide when a patch is debian specific or > not, and then learn a load of tools that they have no use for in order > to keep their personality neatly split. If the change is under debian/, then it is debian specific, otherwise it is not. That's a reasonable rule of thumb, and doing just this would entirely satisfy me. Doesn't need a personality split, in my opinion. There's also the case where upstream and debian maintainer are the same *now*, but that can change anytime. Case in point: there's a package[1] in Debian where upstream & maintainer used to be the same, but not anymore. Nevertheless, for hysterical reasons, upstream is still shipping a debian/ dir, an outdated and crappy one, which, from time to time, still confuses the hell out of people who download the original tarball. That sucks. It's an upstream problem, but it wouldn't have happend in the first place, if packaging & upstream work weren't tied together so tightly in the past. [1]: syslog-ng Anyway, I'll expand on this later, see the end of my mail. > I know a couple of upstreams who use native packages for their stuff, > and I'm pretty sure one or both of them would give up if we insisted > that they add unnecessary and confusing extra steps to their workflow. What steps would be confusing? > Currently they just incorporate the debian directory into their tree, add > a couple of steps to their release Makefile target, and whenever they > release a new version, it's ready for Debian too. Instead of adding a few steps to my release target, I have a script that checks out the debian branch, merges master, and dch -i. It's about 5 lines long, and pretty much the same thing as a Makefile target. I could also wire it into a release target, if I had one. It's neither confusing, nor any extra work, apart from about 5 minutes spent on thinking about the workflow, once. > You're going to have to do a lot better than saying that you don't like > it very much if you're going to convince me that Joey's mistaken in that > choice -- particularly since he comes up with pretty decent arguments in > the opposite direction -- see his answer here: > > > http://ask.debian.net/questions/does-native-package-needs-to-be-debian-specific-if-upstrean-author-is-a-mantainer I don't want to convince you that Joey is mistaken, for he is not. There's nothing inherently wrong with native packages, and there are plenty of cases where they make sense (I maintain two native packages myself, there's no possible way to convince me they should be made non-native), Joey has strong arguments for him handling his packages native, and I agree with him on that. But the same arguments don't hold for everyone. > Certainly there seems to have been no acknowledgement that there are > good examples available that break that rule. I beg to differ: http://lists.debian.org/debian-devel/2013/01/msg00588.html Perhaps I should've phrased it differently, but I believe my message there was quite clear nevertheless. > On the other hand, it's pretty obvious that one will be able to point to > examples where the package clearly should not be native, but that > doesn't tell one much about the general case -- this thread seems to > boil down to: >Look, here's a bad thing, therefore all things are bad. I don't know where you got that from. Most of us posting in this thread have expressed that native packages aren't the problem, their abuse is. In my reading,
Re: No native packages?
Wouter Verhelst writes: > On Sun, Jan 27, 2013 at 07:16:44PM +0100, Jakub Wilk wrote: >> Dmitrijs Ledkovs wrote on his blog[0]: >> >> >Generally if software is useful in Debian Project it can be useful >> >for other debian-like and unlike projects. In particular native >> >packages do not offer the same patching flexibility as 3.0 >> >(quilt), thus forcing downstream distributions to inline modify >> >packages without DEP-3 headers. This hurts us, when trying to >> >merge useful stuff from derivatives back into Debian, as changes >> >are not split into individual patches. >> >> I would tend to agree that we have too many native packages, > > There can only be "too many" of anything if it is (or can be) harmful in > some way to have the thing in question. Perhaps not a convincing argument, but one of the main reasons I mightily dislike native packages for things that aren't Debian specific in any way, is because it sets a bad example. If you see native packages being abused for the sake of convenience, it becomes that much easier to give in to temptation, and use native packaging even when it does have harmful side-effects. By harmful side effects, I mean two things: - Awkward to NMU - Patches not separated While separating patches is often seen as an inconvenience, a useless one at that in the world of SCMs, it does reduce the amount of space needed to store the result, it makes it easier to review the difference between two versions. Granted, one can look at the SCM repository, but there are times when that's far more work than paging through a set of diffs: ie, comparing two versions of a Debian package. If there are diffs, that's easy. If I have to turn to an SCM, I have to figure out its setup (and hope it is documented, which it often is not), and trust that tags and whatnot does reflect what is in the package. That trust is something I do not have, as I've seen it too many times that downstream package and downstream SCM branch did not agree. In an ideal world, this wouldn't be an issue, but we're not living in that world yet. In short, too many native packages, even if they're used in situations where they do not immediately become a problem, does set a bad example, and serves as an excuse to use them even when they're inappropriate. So, for the sake of prospective maintainers, I'd love to get the number of these packages down. > While I agree that in some cases it might be a bad idea to package > something as a native package, for trivial things (like my package > "fdpowermon"), this isn't a big deal; and the overhead of having to deal > with an upstream tarball and/or upstream build system etc is just not > worth it. We have tools that make it easy to create upstream tarballs from an SCM repo. Git has git archive, gitpkg and possibly other tools make it very easy to create upstream tarballs: so much so, that it means nothing more than tagging the repo properly. I've been using this for quite a while for some of my packages (ivykis, libmongo-client), and it doesn't need neither an upstream build system, nor much thought once it is set up. (And setup is fairly trivial too) -- |8] -- 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/87y5fd66jh.fsf@algernon.balabit
Re: No native packages?
Arno Töll writes: > Hi, > > On 27.01.2013 19:32, Gergely Nagy wrote: >> There are two native packages I maintain, and I've yet to hear a good >> reason for making either of them non-native. > > Not knowing your use cases in particular, it would often be good enough > if we could restrict native packages to use cases, where they actually > were designed for. Completely agreed. > We have native packages in Debian where people deliberately use them, > because they are more convenient (i.e. less strict) and easier to use > (no need for orig tarballs). I don't think we should endorse that any > further, so I agree with Jakub in that. Perhaps we should figure out how to make it easier to create orig tarballs (though, gitpkg does a pretty good job there, imo), and prod the native (ab)users to see how their workflow can be made easier even with non-native packaging. -- |8] -- 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/87ehh6mnv1.fsf@algernon.balabit
Re: No native packages?
Jakub Wilk writes: > Dmitrijs Ledkovs wrote on his blog[0]: > >> Generally if software is useful in Debian Project it can be useful >> for other debian-like and unlike projects. In particular native >> packages do not offer the same patching flexibility as 3.0 (quilt), >> thus forcing downstream distributions to inline modify packages >> without DEP-3 >> headers. This hurts us, when trying to merge useful stuff from >> derivatives back into Debian, as changes are not split into >> individual patches. > > I would tend to agree that we have too many native packages, though I > doubt you'll find (m)any supporters of the idea of banning them > completely. There are two native packages I maintain, and I've yet to hear a good reason for making either of them non-native. Making it harder and much much more inconvenient for downstream distributions to modify them is a *goal* in these cases: to make it harder to diverge from one another. As for no DEP-3? I do sincerely hope that by 2013, everyone's using a VCS, and we can pick patches from there. -- |8] -- 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/87libemq8v.fsf@algernon.balabit
Bug#697270: PC 32-bit programs fails to work on amd64
Alexey Eromenko writes: > User error? Huh ? It is, I'm afraid. > No ! This is a Debian Bug ! No, it is not. > Debian clearly says: "File does not exist", while in fact it DOES > EXIST. It does not. However, the file the message is referring to is not the file you think it refers to: it is missing the 32-bit dynamic linker, /lib32/ld-linux.so.2 (available in the package libc6-i386), not the firefox binary itself. The message is a bit confusing, indeed, but without a dynamic linker present, it's hard to do any better. > This is a 100% proof of Debian bug. You installed a 32-bit application on a 64-bit system. That will only work if you also install the 32-bit supporting libraries, including the dynamic linker. This is not a bug in Debian. And no, installing 32-bit libraries by default would be a bad idea, for a multitude of reasons. -- |8] -- 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/87vcbei1w9.fsf@algernon.balabit
Re: Gentoo guys starting a fork of udev
"Andrej N. Gritsenko" writes: > Hello! > > Gergely Nagy has written on Wednesday, 21 November, at 10:29: >>Matthias Klumpp writes: > >>> For syslogd, systemd provides journald for those who want to use it, >>> but the Journal is no dependency of systemd. > >>Wrong. You can't have any recent systemd without the Journal, and >>'legacy' syslogds are piggybacking on /run/systemd/journal/syslog, where >>the journal forwards syslog messages to. There's no way around that, you >>can't turn the journal off. > > Does all that mean I cannot have /var/log/* logs with systemd? If > it's so then systemd should never come into any server installation at > the very least. If you read my mail further, your question is answered there. But I'll repeat it, for good measures: no, it does not mean that. I only means that your syslogd of choice is getting its input from /run/systemd/journal/syslog instead of /dev/log. -- |8] -- 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/87obiqa75z@luthien.mhp
Re: Gentoo guys starting a fork of udev
Matthias Klumpp writes: > For syslogd, systemd provides journald for those who want to use it, > but the Journal is no dependency of systemd. Wrong. You can't have any recent systemd without the Journal, and 'legacy' syslogds are piggybacking on /run/systemd/journal/syslog, where the journal forwards syslog messages to. There's no way around that, you can't turn the journal off. > (Since most stuff uses syslog calls, this is not an issue. Also, > systemd does not require journald, even for Fedora it is not safe yet > if they will use the journal or not) What Fedora & co are considering, is not requiring the journal (it comes enabled since F17 already), but having no 'legacy' syslogd installed by default along with it. [1] [1]: http://fedoraproject.org/wiki/Features/systemd-journal -- |8] -- 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/87r4nn2tj0.fsf@algernon.balabit
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Bart Martens writes:
>> > I think that sufficient DDs will review the ITOs. Note that most work is
>> > already done by the ITO submitter. Sponsoring a package at mentors
>> > ("review
>> > other peoples work") is, in my opinion, much more work than reading an ITO
>> > and
>> > sending an ACK.
>>
>> On the other hand, ACKing an ITO is much more responsibility, becasue
>> it's not only about a package, but about taking over a package too.
>
> No, it is not. See the "two activities" explained here:
> http://lists.debian.org/debian-devel/2012/10/msg00261.html
It is still more responsibility than sponsoring, whether you orphan or
take over the package, because you're not just introducing a new package
or a new version as with sponsoring, you're not just doing an NMU, but
you're taking away something from someone. This latter part is what - in
my opinion - makes ACKing an ITO a much bigger thing than sponsoring or
NMUs.
>> An
>> ITO will also contain quite a lot of info about previous attempts at
>> updating the package - that's not simple to review either. It is less
>> technical too, which can be off-putting to some.
>
> No, an ITO should just enumerate the reasons why the package should be marked
> as orphaned.
And the reasons why the package should be orphaned overlaps quite a bit
with previous attempts at getting the package fixed/updated/whatever by
other means.
If there were no previous attempts, then the package should not be
considered for ITO.
>> >> As said elsewhere in the thread, the process needs to be easy and
>> >> efficient. Hunting ACKs is neither easy, nor efficient.
>> >
>> > The proposed text is quite easy, in my opinion.
>>
>> Indeed, it is. Partly because as far as I understand it, it only
>> recommends a 3/1 majority, and does not demand it. That's perfectly
>> fine.
>
> I guess it's a recommendation because it would go in developers-reference.
> That doesn't mean that it would be OK to randomly orphan packages ignoring the
> recommended procedure in developers-reference.
I never said ignoring the recommended procedure. CC-ing -qa@ is a must,
I never said otherwise. I merely said that *waiting* for ACK/NACK
replies should have a timeout, and if no response arrives within a
reasonable amount of time, we should default to allowing the salvager to
proceed.
That is all. Without the timeout, we have a hole in the system: how long
do you have to wait for replies? When is majority reached? As soon as
3/0? What if that happens within 10 minutes, and a NACK would come on
the 15th? If waiting for majority does have a timeout, what happens if
there are no replies for one reason or the other?
These I'd love to see clarified. Personally, I'd go with 2-3 weeks tops,
and default to yes in case of no replies, on the grounds that mistakes
can be corrected, and we should be civilised enough to not flame the
salvager to crisp if that happens (since it was us who failed to give
him feedback in the first place - punishment shall be on us, not the
salvager).
--
|8]
--
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/87d305y88b@luthien.mhp
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Steve Langasek writes: >> > > No, it makes the process based on *consensus*, which is a minimum >> > > requirement. > >> > It also means that the salvager has to do more work. > >> I expect the cc to debian-qa to draw sufficient DD's attention. And the >> ACKs are about agreeing on marking a package as orphaned. That's the easy >> part. > >> The salvaging part goes via the existing ITA procedure. That's the hard >> part. > > Exactly. Anyone who can't be bothered to find N other DDs to agree with him > that a package should be orphaned (for some value of N <= 3 - as far as I'm > concerned, 1 or 2 acks w/ 0 nacks is sufficient) shouldn't be considering > themselves a candidate for maintaining the package anyway. I am then unfit to maintain any package, since I would not be willing to do more than CC -qa@ by the time it comes to an ITO, to draw attention. If I get no answer to that, no acks, no nothing (and similar things did happen in the past, perhaps not on -qa, but I have mails on -devel@ and -release@ unanswered, or complained about months later after the fact), I would not want to go out of my way to find consensus. I take no replies (within a reasonable timeframe) as not caring, as silent agreement. By the time -qa@ is mailed, the salvager had to do enough visible work to draw attention to the eventual ITO, so mailing -qa@ should be enough, whether that gets the salvager any acks or not. In case of no acks, it is *NOT* the salvagers fault that noone cares, and therefore it is not the salvager who should be punished with more gruntwork, either. I don't really see the point of requiring consensus if there are *zero* replies to an ITO CC'd to -qa@ for, say, 2-3 weeks. On a similar note, the original proposal did not mention how much time needs to pass before the salvager can proceed, after getting a majority. THAT too, needs a timeout, and if it does, why would it hurt to bake in a worst-case scenario with no acks or nacks? (I can accept defaulting to no too, after a timeout, as long as there's one. I would find the result pointless and silly, but at least it puts an end to it, which the current proposal doesn't.) -- |8] -- 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/87haphy8ql@luthien.mhp
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Ian Jackson writes: > Whether a package is in need of greater attention is not a hard and > fast objective thing. It's to a large part subjective. Perhaps the > maintainer thinks it's more or less fine, or at least low enough > priority that the problems are tolerable. Then the maintainer has many options, including but not limited to NACK-ing the ITO. One has a lot of possibilities even before it comes to filing an ITO. > It's one thing to say "this package is in need of attention which I am > prepared to commit to providing". It's quite another to say "this > package is in need of attention but I'm not going to do anything other > than say it's a problem". There is, indeed a difference, but the latter allows someone else (potentially a non-DD) to take over the package, and make it visible that the package is in need of a new maintainer. That alone is already a tremendous improvement compared to papering over the issue. -- |8] -- 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/87ehkma8mg.fsf@algernon.balabit
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Bart Martens writes:
> On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
>> Steve Langasek writes:
>>
>> > On Tue, Oct 23, 2012 at 02:40:39PM +0200, Stefano Zacchiroli wrote:
>> >> > 4. When/if consensus has been reached, the package can be orphaned by
>> >> >retitling and reassigning the ITO bug accordingly.
>> >
>> >> I fear a bit the situation "nobody care enough to comment", being
>> >> interpreted as lack of consensus. But I do think in that case we should
>> >> _eventually_ allow the orphaning to happen (after all 1/0 > 3/1 ACK/NACK
>> >> ).
>> >> Any suggestion on how to word that properly, without adding yet another
>> >> timeout rule carved in stone?
>> >
>> > I disagree on this point. If you can't get anyone to ack that you should
>> > go
>> > ahead with the orphaning, then the system is not working as designed and
>> > consensus has not been achieved. It's then incumbent on the person looking
>> > to orphan the package to rattle the cage and get developers to pay
>> > attention.
>>
>> On the other hand, it is already hard to find people willing to review
>> other peoples work. Mandating acks means trusting that there will be
>> enough manpower to review something potentially unknown. I can't see
>> that happening reliably.
>
> I think that sufficient DDs will review the ITOs. Note that most work is
> already done by the ITO submitter. Sponsoring a package at mentors ("review
> other peoples work") is, in my opinion, much more work than reading an ITO and
> sending an ACK.
On the other hand, ACKing an ITO is much more responsibility, becasue
it's not only about a package, but about taking over a package too. An
ITO will also contain quite a lot of info about previous attempts at
updating the package - that's not simple to review either. It is less
technical too, which can be off-putting to some.
>> It also makes the process a whole lot more
>> complicated than it needs to be, which in turn allows the package to
>> suffer unmaintainance longer, decreasing the distributions overall
>> quality.
>
> It's not so complicated to find three DDs to agree with the ITO.
Not terribly so, perhaps. But if the salvager has already gone to great
lengths to save a package, pushing even more work on him is not going to
help.
(Mind you, I'm not against the ACK/NACK system, I'm only arguing for
being able to proceed without N acks after a reasonable amount of time.)
>> As said elsewhere in the thread, the process needs to be easy and
>> efficient. Hunting ACKs is neither easy, nor efficient.
>
> The proposed text is quite easy, in my opinion.
Indeed, it is. Partly because as far as I understand it, it only
recommends a 3/1 majority, and does not demand it. That's perfectly
fine.
--
|8]
--
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/87sj92ahzh.fsf@algernon.balabit
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Steve Langasek writes: > On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote: >> > I disagree on this point. If you can't get anyone to ack that you should >> > go >> > ahead with the orphaning, then the system is not working as designed and >> > consensus has not been achieved. It's then incumbent on the person looking >> > to orphan the package to rattle the cage and get developers to pay >> > attention. > >> On the other hand, it is already hard to find people willing to review >> other peoples work. Mandating acks means trusting that there will be >> enough manpower to review something potentially unknown. I can't see >> that happening reliably. It also makes the process a whole lot more >> complicated than it needs to be, > > No, it makes the process based on *consensus*, which is a minimum > requirement. It also means that the salvager has to do more work. By the time we get to salvaging, other means of getting the package fixed/updated have already been exhausted - that's quite a lot of work already, and by that time, it should be very clear that salvaging is the way to go forward. I do agree that the salvager should seek consensus, and should make a reasonable effort to get some feedback on his/her intention, BUT I would not make that mandatory (seeking acks - yes; not being able to go forward until N acks - no), as that will stall the process for far too long in case of less popular packages (and as far as I see, those less popular packages would benefit most from the salvaging process). THAT is what I'm concerned about. And seriously, if noone ACKs or NACKs a salvaging proposal for an extended period of time, to me, that means noone cares enough. If noone cares, noone minds, then I would put my trust behind the developer, to know what he's doing, and let him proceed. Would a mistake be made, that can always be corrected. >> which in turn allows the package to suffer unmaintainance longer, >> decreasing the distributions overall quality. > >> As said elsewhere in the thread, the process needs to be easy and >> efficient. Hunting ACKs is neither easy, nor efficient. > > The debian-qa list served this purpose fine for *years*. It's not > acceptable to use handwavy assertions about manpower to justify an > antisocial process. If the debian-qa list continues to serve this purpose well, then there is no issue: we'll never see the case I'm worried about, and I'll be the happiest person on earth. If we do end up in such situations, though... -- |8] -- 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/87wqyeaie2.fsf@algernon.balabit
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Steve Langasek writes: >> So, what will you do if: >> - previous maintainer goes MIA >> - Somebody wants to hija^W salvage the package and starts the procedure >> - Nobody votes for this to happen... > >> Should we then leave the package forever unmaintained? >> I don't think this is reasonable... > > And I don't think this is a realistic scenario. Why can't you find N other > DDs who agree with you that the package should be taken over? This is not a > high bar. I don't really have any sympathy for the argument that the entire > Debian project might decide not to care about the package you're concerned > about and therefore you need to take matters into your own hands and take it > over. Not a high bar, but still far more work than it needs to be. Salvaging is meant for cases where it is desperately needed, which, I believe, are quite clear cases. I find it unreasonable to demand ACKs, when one already went to great lengths to solve the issue without taking over maintainership. If there's dispute later, any change can be reverted then, or taken to the tech-ctte. I do not see any reason to make the process long and tedious, we should *NOT* punish the salvager for trying to bring a package back to life. We should make that as easy and painless as possible, once other options failed. Would a mistake happen, it can and should be corrected, but that should be the exception, not the norm. And as such, the process should not follow the exceptional cases, but the most common ones. So while I do agree that ACKs/NACKs can be helpful, making them mandatory would - I believe - be counter productive. If noone cared enough to respond with neither ACK nor NACK, go ahead. Not voting means one does not care. It is entirely possible that the vast majority of the project won't care about a particular package, and that should not be an obstacle on the path of salvaging it. -- |8] -- 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/871ugmbxii.fsf@algernon.balabit
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Steve Langasek writes: > On Tue, Oct 23, 2012 at 02:40:39PM +0200, Stefano Zacchiroli wrote: >> > 4. When/if consensus has been reached, the package can be orphaned by >> >retitling and reassigning the ITO bug accordingly. > >> I fear a bit the situation "nobody care enough to comment", being >> interpreted as lack of consensus. But I do think in that case we should >> _eventually_ allow the orphaning to happen (after all 1/0 > 3/1 ACK/NACK >> ). >> Any suggestion on how to word that properly, without adding yet another >> timeout rule carved in stone? > > I disagree on this point. If you can't get anyone to ack that you should go > ahead with the orphaning, then the system is not working as designed and > consensus has not been achieved. It's then incumbent on the person looking > to orphan the package to rattle the cage and get developers to pay > attention. On the other hand, it is already hard to find people willing to review other peoples work. Mandating acks means trusting that there will be enough manpower to review something potentially unknown. I can't see that happening reliably. It also makes the process a whole lot more complicated than it needs to be, which in turn allows the package to suffer unmaintainance longer, decreasing the distributions overall quality. As said elsewhere in the thread, the process needs to be easy and efficient. Hunting ACKs is neither easy, nor efficient. -- |8] -- 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/87zk3caxpj.fsf@algernon.balabit
Re: Discarding uploaded binary packages
Tollef Fog Heen writes: > ]] Jakub Wilk > >> What makes a buildd more secure than a machine of J. Random Developer? > > It has a smaller attack surface due to few users, firewalls, few > packages installed, nobody using it for browsing the web, etc. We seem to be forgetting, that the real advantage of source-only uploads isn't necessarily security, but a controlled build environment on *all* architectures. There is sbuild, pbuilder and the rest, but there are still packages uploaded that are built in an unclean environment, thereby becoming broken in various interesting ways. Nevermind security, whether N buildds are more secure than 200N random systems scattered around the world - a controlled environment makes source-only uploads a win, without doubt. (Of course, there's the corner case of bootstrapping things, but that's a corner case, and should be handled as such, not as the norm.) -- |8] -- 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/87r4oy335m.fsf@algernon.balabit
Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal
Lucas Nussbaum writes: > On 11/10/12 at 05:50 +, Bart Martens wrote: >> | Anyone can mark a package as orphaned after the following steps have >> been >> | completed : Someone submits an "intent to orphan" (ITO) in the bts with >> an >> | explanation of why he/she thinks that the package needs a new >> maintainer. The >> | explanation should cover aspects like how long there was no visible >> activity, >> | whether there are NMUs not yet acknowledged, wheter the package blocks >> progress >> | elsewhere in Debian, release critical bugs, public comments from the >> maintainer >> | revealing lack of interest in the package, ... etc. The bug must have >> severity >> | "serious" and a cc must be sent to the debian-qa mailing list. Anyone >> can >> | submit this "intent to orphan". At least three DDs (not counting the >> initial >> | submitter) second the "intent to orphan" on the same bug report with a >> cc to >> | the maintainer. If some DDs send NACKs instead, then a 3/1 majority is >> needed >> | between ACKers and NACKers. > >> And the maintainer does not respond within one month after the the third >> second. > > I'm not sure about this delay. This procedure should be used for > uncontroversial cases, where orphaning is obviously the right choice. I strongly agree here. A package that's a salvaging candidate has already been neglected far too long, requiring another extra month of at most NMU-maintainance is counter productive. A maintainer has many ways to signal in advance that he/she will be unable to answer bug reports or mail for a longer period of time (including VAC messages on -private, and/or setting a vacation message in LDAP), many of which can and should be checked as soon as the salvaging process starts, to make sure there's no accidental overlap. With that done, I do not see the point of waiting an extra month. I would, however, put a time limit on the NACKs: one week after 3 ACKs or 3/1 majority is reached, the decision's done, and further ACKs/NACKs won't be counted. That is, we'd have a time limit on everyones ability to contribute to the salvaging process, not just a ticking clock for the maintainer. > Maybe rephrase that into "Before taking action, it could also be a good > idea to wait for comments from the maintainer, especially if he/she is > otherwise active in Debian." I'd rephrase that further, with a s/wait for/seek/, because in my opinion, the person wanting to salvage a package should go to great lengths to reach the maintainer. Merely waiting when the package is obviously neglected sounds like a very passive thing to me. -- |8] -- 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/87r4p58llk.fsf@algernon.balabit
Re: Changes to Debian Maintainer upload permissions
Paul Tagliamonte writes: > If any DM asks me to, and they can show they've made uploads (with > DMUA) before this announcement for that package, and that they've not > broken things in a gnarly gnarly way (and if their sponsor is VAC, > MIA or otherwise not here), I don't think I'd have any problem flipping > the bit back over. > > Yes, even if I'd not have given them DMUA on my own. Yep, that is one of the solutions I mentioned earlier. Therefore, if a DM does care, migrating to the new system is by all means possible, and they have very little to do, they will not be punished for another person's absence or mistake. -- |8] -- 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/87vcf65fvu@luthien.mhp
Re: Changes to Debian Maintainer upload permissions
Arno Töll writes: > On 22.09.2012 10:06, Ansgar Burchardt wrote: >> We are using this opportunity to clean up the "DM database" and will not >> convert any of the DMUA flags to the new format, but two months ought to >> be enough for any active DM to ensure their sponsor DDs have set the new >> permission. > > please don't. This is not only to work out active DMs, but also a denial > of service attack against active DMs where their former sponsor is > unavailable or disappeared since then. It's not necessarily the DMs > fault, if he fails to get _someone else_ to send a "be-alive" message > within two months. I am sure that on the rare occassion where the DM faces this kind of trouble, we will be able to find a suitable solution. I don't think anyone wants to punish DMs, quite the contrary. I do not think there is any need to worry, no active DM will be left behind. So if any DM is having an issue along these lines, yell, and I am sure some solution will be found. (I can think of at least three solutions, and only one requires more work from the DM, but results in that M turning into a D, which can also be beneficial in the long run!) -- |8] -- 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/87zk4i5o0j@luthien.mhp
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Philipp Kern writes: > On Mon, Aug 20, 2012 at 10:32:07AM +0200, Gergely Nagy wrote: >> If neither upstream, nor porters care about a particular package, that >> means there are very little use of having it on that port, and one >> should consider changing the Architecture line to exclude the failing >> port. >> >> That's about a minute of work + an RM request for that port: another >> minute or two. I don't think this is a bad thing, or something *any* >> maintainer should find troublesome. > > That's untrue. An RM request might have far reaching consequences. It can mean > that another package gets uninstallable, which then requires editing its > Build-Dependency list if it can be built on the target architecture without > it. > And that might trickle down to many packages. AFAIK that's basically the > approach the GNOME maintainers use and it means that despite the package not > being tested (and possibly used) at all on those architectures, you need to > carry on a lot of excludes for that port and possibly cripple the platform. Indeed, there are parts of the archive that are far more complicated than the rest, where an RM request has far reaching consequences. I'd like to believe that is the exception, though. -- |8] -- 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/87mx1oej3u.fsf@algernon.balabit
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Charles Plessy writes: > Le Sun, Aug 19, 2012 at 11:13:23PM +0200, Gergely Nagy a écrit : >> Michael Biebl writes: >> >> > If those ports need a GR to silence any criticsm regarding those ports, >> > then something is going seriously wrong. >> >> I've yet to see said criticism. > > In the absense of regression tests, we distribute thousands of packages that > nobody knows if they work or not, because nobody ever used them. That's not a criticism against the port, but a criticism against packages not having tests. It is by no means the fault of the port that packages are not properly tested, as that applies to every single one of them. > Then one day they happen to fail to build, or regression tests are implemented > and crash, and suddenly the maintainer has to take care of development issues > that are not supported upstream nor by the porters. If neither upstream, nor porters care about a particular package, that means there are very little use of having it on that port, and one should consider changing the Architecture line to exclude the failing port. That's about a minute of work + an RM request for that port: another minute or two. I don't think this is a bad thing, or something *any* maintainer should find troublesome. > We need to take this specialisation into account, be proud of what > our ports bring to their users, and be more open-minded about ignoring > combinations of softwares and architectures that were never designed > to work together. Indeed. > There is a simple heuristic to detect such cases, it is when the only help a > maintainer receives is guidance on how to ask for a login on the porter box > and > fix the package himself. If neither upstream, the users and the porters care, > then we need to provide to the maintainer some ways to ignore issues without > having to spend time on requesting architecture-specific archive > removals, etc. What's wrong with requesting arch-specific removals? It doesn't take a lot of time, perhaps at the other end. But then, such removal requests are - judging by a quick glimpse of bugs-dist - aren't all that common to warrant special treatment of any kind. -- |8] -- 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/87fw7im0ag@luthien.mhp
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Michael Biebl writes: > If those ports need a GR to silence any criticsm regarding those ports, > then something is going seriously wrong. I've yet to see said criticism. -- |8] -- 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/874nnyio0c@luthien.mhp
Re: Change default PATH for Jessie / wheezy+1
David Given writes: > Thomas Goirand wrote: > [...] >> Exactly what do you need from sbin as a user? > > I use stuff from sbin as user all the time. A quick glance at /sbin > shows these commands that I use on a regular basis: > > blkid > fdisk > all the fscks > all the mkfss > hdparm > ifconfig (before this discussion I'd never even *heard* of ip) > iwconfig > mount.cifs > parted > route > showmount > > Like the parent, I add /sbin and /usr/sbin to my path immediately after > installing a new Debian system. But, you know what those commands do, and I think we can agree, that most - if not all - of them are quite close to being tools for the admin, even if they don't necessarily require root. A 'regular' user on a multi-user system will not likely need any of them. It *might* make sense to (optionally) add */sbin to the PATH of the first user installed. I wouldn't add it for everyone else too, however. -- |8] -- 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/877gt9myyz.fsf@algernon.balabit
Re: Recommends for metapackages
Miles Bader writes: > Gergely Nagy writes: >> if upstream considers a package a core part of a platform, >> recommends *is* wrong. > > Er, no. > > Upstreams are not infallible, and are often quite fallible... > > Upstream's "view" is a good _default_, but such judgements should be > made based on the reality on the ground. In that case, recommends still is wrong. Either split the package then (and then both parties win), or drop a component completely (or demote to suggests). -- |8] -- 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/874npc6ooa.fsf@algernon.balabit
Re: Recommends for metapackages
Gergely Nagy writes: >> Please don't forget that a Recommends will pull in packages in all but >> unusual installations :) > > But also keep in mind, that once a package is installed, adding new > recommends will not pull those new things in on an upgrade. I've been corrected, that this statement is not valid, and a dist-upgrade will pull them in. Sorry about that. However, Recommends: will not keep them installed, so if the meta is a platform, which should be intact and complete, recommends is still not an option. -- |8] -- 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/87liiorvax@luthien.mhp
Re: Recommends for metapackages
Andrei POPESCU writes: > On Jo, 12 iul 12, 17:44:52, Gergely Nagy wrote: >> >> > Then some time later during upgrade it'll upgrade all packages >> > but will not install N-M; at the same time it'll install >> > new package that was added to Recommends in that new version. >> >> As far as I remember, it will not install new recommends. > > http://lists.debian.org/caaz6_fdtaydt1ubp08yf0d8l0jusffy1rzyhvmvztfcjeoc...@mail.gmail.com Hmm, right. dist-upgrade will pull new recommends in, indeed. Well, there goes one argument against Recommends. The rest still stands, though. >> But, the problem I'm talking about is not related to this. The problem I >> see is when I have a gnome meta-package, that recommends, say, >> totem. Now, lets suppose I'm also running unstable, for one reason or >> the other, and a transition comes along, and something has a breaks on >> stuff totem depends on, and the package manager decides to remove totem. >> >> Weeks later, when I want to watch a movie, at the end of the world, with >> no network connectivify, I realize that something pulled my movie player >> out of me. >> >> I would be very, very sad. >> >> Of course, silly me, why do I run unstable? And why don't I pay >> attention to what my upgrades do? Well, I run unstable because I work >> with it, and it has up-to-date stuff I have to work with. And running >> unstable is far easier than running testing and cherry-picking (did I >> mention I hate manual bookkeeping?). I do unattended upgrades, because I >> trust the system to keep everything I installed, installed. I installed >> the gnome meta-package because I want the full thing, bells, whistles >> and crap included. > > Sorry, but IMNSHO running sid with unattended upgrades just asks for > trouble. But then again IANADD, if Debian wants to optimize for this use > case who am I to disagree? :) Similar issues can happen in stable, less often, and for different reasons, but the possibility still exists. Also - and this easily happens in stable too -, there's the problem of trying to remove a dependency of a recommended package. That will happily remove the recommended package, and keep the meta. A user may or may not know what those strangely named packages that get removed are, and making him look it up, and watch every upgrade like a hawk isn't exactly friendly. >> I could, of course, mark totem manually installed, but then I'm back to >> manual bookkeeping, could've installed the whole stuff by cherry-picking >> each component, and that makes the meta-package useless for me, and >> destroys the argument that recommends would result in less bookkeeping. >> >> Thus, here's an example where Recommends *will break* an existing >> system. >> >> Oh, and since apt won't install new recommends on upgrade, to the best >> of my knowledge, I won't get totem back once the >> transition/breakage/whatever is fixed, either. While if it would be a >> dependency, the upgrade would abort, because it'd try to remove a >> package marked as manually installed. >> >> But similarly, if I ran stable, and one of the meta packages I installed >> had a recommends on a piece of software, and I try to install something >> that conflicts with it (either directly, or indirectly, via another meta >> package, for example), then this piece of software gets removed. I may >> or may not notice that - I might not even know wtf totem is, a novice >> user who first sees Linux certainly won't - so it gets removed. > > Well, if the purpose of the Depends are to protect a novice from > removing packages by mistake that surely a package manager offering to > remove 100+ packages should definitely sound an alarm. Yep, and it sounds an alarm: "do you want to remove all this stuff, *including* the meta?" Vs "do you want to remove 1/10 of that stuff, most of which you never heard of so who cares?" > But with apt-get you will get only two packages uninstalled (the package > with the conflict and the metapackage depending on it). The big surprise > will come only later, when apt-get suddenly suggest you should run > 'autoremove' to get rid of some 100+ packages that look like not needed > anymore. Yes. But it's easier to notice the removal of gnome (and stop it), than the removal of one of the components of the platform, of which one possibly never even heard of before, just uses, as it's part of the platform. On one hand, you have, in the depends case: # apt-get remove gstreamer-plugins-good Which will try to remove the whole world, including the meta
Re: Recommends for metapackages
Andrei POPESCU writes: > On Jo, 12 iul 12, 12:10:29, Gergely Nagy wrote: >> >> Erm, how have I broken my system? I did not. (Turning Install-Recommends >> off is definitely not breaking my system, FYI.) > > It means you are running with a non-default configuration and you should > be aware of the side-effects. I am aware of side-effects, thank you. I turn it off because of the side-effects. That does not make my system broken, however. > Please don't forget that a Recommends will pull in packages in all but > unusual installations :) But also keep in mind, that once a package is installed, adding new recommends will not pull those new things in on an upgrade. I do not think upgrade is an unusual situation, fwiw. For stable, it is, for everything else, not so much. But half the arguments for Recommends (with regards to meta-packages) are invalid for stable anyway. The only valid argument for stable is that apt-get remove gnome will want to remove a whole bunch of stuff. My counter argument is that doing so is safer than screwing up the user's system. -- |8] -- 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/87txxcrwu3@luthien.mhp
Re: Recommends for metapackages
Andrei POPESCU writes: > On Jo, 12 iul 12, 15:46:05, Gergely Nagy wrote: >> >> X) Downgrade stuff to recommends >> >> >> I do not consider this a solution, for reasons explained elsewhere, >> where my main concern is that it breaks the assumption that installing a >> platform (in this case, gnome) will install the whole thing, and it will >> be available for my use at any time. > > Well, it will, in all but unusual installations :) No. See below. >> With recommends, there's a fair chance that a distinctly related package >> forces part of the platform off, and the package manager will happily >> remove them. Once the breakage is fixed, it will not reinstall them. > > Could you please elaborate on that? The only thing I can think of that > would force some packages to not be installed (or removed) is a > Conflicts (or unsatisfiable Depends, but this shouldn't happen in > stable). As far as stable is concerned, a conflict, yes. For unstable, where package releations are more interesting, unsatisfiable Depends too. > With Recommends you get a simple prompt that a specific package will be > uninstalled and comparing the descriptions will probably give a hint to > any user that those packages might conflict (assuming they don't look at > the Conflicts). So, on each upgrade, the user would need to: - Double guess the system, to not botch an upgrade - Read N number of package descriptions to figure out wtf that thing it wants to remove is. How is that user friendly and good? > With Depends aptitude will suddenly want to remove a whole bunch of > packages (that may or may not look related) and apt-get will suggest you > to do this via autoremove. Then you have go hunting with apt-mark, > yay! With Depends, I will instantly know something is botched. With recommends, it will happily remove half the platform unless I stop it manually. Which I most likely wont, as I'm doing unattended upgrades. And I do unattended upgrades, because I trust the system to do the right thing, and not remove stuff from under me that it should not. I *hate* doing things manually, that's why I'm using a bloody high-level package manager. If it forces me to double-guess it, check a lot of things during upgrades, I might aswell go back to downloading packages by hand and using dpkg directly myself. >> This can be worked around by removing the auto-installed flag from those >> parts of the platform that I want to keep at all times, but then what is >> the use of Recommends, when I have to cherry pick anyway? I could just >> skip installing the meta, the net effect is the same (except, that >> without the meta, there are no expectations to break). > > Are you talking about testing or sid? Either. >> I still don't see the problem with installing a subset by hand. Advanced >> users can script it, novices will only need to hand pick once. Done. 10 >> minutes job. > > IMO the main problem is: > > # aptitude remove package > Following packages will be removed: > [Big list with 100+ packages] How is that better than: # aptitude upgrade Following packages will be removed: [A list of 10+ packages you have no clue about] A novice user will answer no to the former, and keep his system intact. He will answer yes to the latter, because he never heard of those packages before, and trusts the package manager to do the right thing. Hi, you have a broken system. But, it can also happen when you remove a dependency of a recommended package: # aptitude remove dependency-of-a-recommended-package [ List of 10+ packages you have no clue about ] There goes your video player, your audio player and probably a bunch of other things. Unless the user double-checks what those 10+ packages are, which most likely he won't. >> Compare that to the hours wasted trying to figure out what forced part >> of the platform off my system and when, during an unattended >> upgrade.. Yes, I do those, because I want to trust the system doing the >> right thing, and keeping stuff I installed intact and complete. > > Sorry, I thought we were talking about stable, why would something like > that happen. If we're talking about stable only, there's even less reason for Recommends. -- |8] -- 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/87y5morx0a@luthien.mhp
Re: Recommends for metapackages
Tollef Fog Heen writes: > ]] Gergely Nagy > >> Instead of fighting for Recommends, which would break your system in >> various interesting ways later on[1], there's a third solution: noone >> stops anyone from uploading a gnome-minimal package, which depends on >> gnome-session and a few selected other parts, without n-m. > > I would think it quite rude to trample on the gnome-* namespace unless > this is well coordinated with the GNOME packagers. If they're happy > with it, that's a different situation. I agree. But from what I've seen so far, it seems to me that it would be far easier to persuade the relevant people to accept a new meta, than to downgrade anything to Recommends. (Also a much better idea than Recommends :) -- |8] -- 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/87629stc7k@luthien.mhp
Re: Recommends for metapackages
Wouter Verhelst writes: > On Tue, Jul 10, 2012 at 04:18:17PM +0200, Gergely Nagy wrote: >> "Eugene V. Lyubimkin" writes: >> >> > On 2012-07-10 15:32, Josselin Mouette wrote: >> >> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : >> >> > What's wrong with Recommends: in that case? It seems to perfectly >> >> > match the "makes life easier for > >> > XXX>" scenario you describe. >> >> >> >> Recommends is wrong for metapackages because it gets upgrades very >> >> wrong. This is why it is used very marginally. >> > >> > Standards should not depend on implementation details. I see zero >> > reasons why metapackages are (or should be) specific here. Whatever $it >> > that gets upgrades wrong should be fixed instead. >> >> But the purpose of the meta-package is to pull stuff in. Depends does >> that, Recommends does not, therefore Recommends is not appropriate for >> the task. > > Of course it does. Five years ago, when apt didn't install recommends by > default, recommends might not have been appropriate, but these days it > is. Does it pull in recommends on upgrade? No? Just how useful are they then, for following the changes in the meta? Does Recommends guarantee that the platform will stay intact, unless I explicitly remove a recommended package? No? That'll be fun! "I installed gnome, but an upgrade wants to remove totem! What's up with that??" Is no better than "I installed gnome, but an upgrade wants to remove it altogether", except the former is more dangerous, as it wants to remove a package you didn't install by hand, and may not know what it does. For novice users, the former is far more dangerous, because they may not know what the removed package is for. At least with Depends, the same upgrade would want to remove the Gnome metapackage, and they'd know what THAT is, and can stop the upgrade. No, recommends are a terrible idea for meta-packages. -- |8], who still doesn't like being CC'd on list mail. -- 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/87a9z4tcbd@luthien.mhp
Re: Recommends for metapackages
FTR: Please don't CC me on list mail. I'm tired of setting M-F-T. Tomasz Rybak writes: > Dnia 2012-07-12, czw o godzinie 15:46 +0200, Gergely Nagy pisze: >> Tomasz Rybak writes: >> >> > At first I thought it was a joke. But no, you really suggest that >> > everyone who wants to have up-to-date desktop environment >> > but without few packages (e.g. N-M or GDM) needs to create own package, >> > own local repository, and looks into it every time there is upgrade >> > to keep it current? And this is supposed to be simple? >> >> Please read the rest of the mail, and the rest of the thread, where I >> explain that Recommends gets you into the same manual bookeeping >> situation anyway. > > I might be misunderstanding situation with dependencies here then. > > Let's assume that I have set my system to install recommended > packages by default and I try install "gnome" package. > It has some packages in Depends, some in Recommends. > If it has N-M in Recommends, I can unselect it during installation. Yes. And you can remove it later too. > This will result with my system having gnome with all its dependencies > and recommendation installed except for N-M. Yes. > Then some time later during upgrade it'll upgrade all packages > but will not install N-M; at the same time it'll install > new package that was added to Recommends in that new version. As far as I remember, it will not install new recommends. > It this correct description of apt behaviour, or have > I misunderstood something? More or less, except that to the best of my knowledge, it will not install new recommends on upgrade. And that makes sense, and is good so, otherwise it will attempt to install all recommends I explicitly did not install on each upgrade - no thanks. (Or we need to introduce yet another complexity into the system, to mark packages as not-to-install-ever. I doubt we have that now... but perhaps hold on an uninstalled package works that way? I don't know.) But, the problem I'm talking about is not related to this. The problem I see is when I have a gnome meta-package, that recommends, say, totem. Now, lets suppose I'm also running unstable, for one reason or the other, and a transition comes along, and something has a breaks on stuff totem depends on, and the package manager decides to remove totem. Weeks later, when I want to watch a movie, at the end of the world, with no network connectivify, I realize that something pulled my movie player out of me. I would be very, very sad. Of course, silly me, why do I run unstable? And why don't I pay attention to what my upgrades do? Well, I run unstable because I work with it, and it has up-to-date stuff I have to work with. And running unstable is far easier than running testing and cherry-picking (did I mention I hate manual bookkeeping?). I do unattended upgrades, because I trust the system to keep everything I installed, installed. I installed the gnome meta-package because I want the full thing, bells, whistles and crap included. I could, of course, mark totem manually installed, but then I'm back to manual bookkeeping, could've installed the whole stuff by cherry-picking each component, and that makes the meta-package useless for me, and destroys the argument that recommends would result in less bookkeeping. Thus, here's an example where Recommends *will break* an existing system. Oh, and since apt won't install new recommends on upgrade, to the best of my knowledge, I won't get totem back once the transition/breakage/whatever is fixed, either. While if it would be a dependency, the upgrade would abort, because it'd try to remove a package marked as manually installed. But similarly, if I ran stable, and one of the meta packages I installed had a recommends on a piece of software, and I try to install something that conflicts with it (either directly, or indirectly, via another meta package, for example), then this piece of software gets removed. I may or may not notice that - I might not even know wtf totem is, a novice user who first sees Linux certainly won't - so it gets removed. It won't come back, unless I install it. As far as I'm concerned, this defeats the purpose of the meta-package, because it breaks my expectation that whatever else it pulls in, will stay there as long as the meta is installed. Perhaps that is a silly assumption, but if it is, then there's no point in having anything in a meta's depends at all, as it's pretty much a supermarket you can cherry pick from. In that case, I would be very disappointed. -- |8] -- 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/87hatd6l1n.fsf@algernon.balabit
Re: Recommends for metapackages
Tomasz Rybak writes: > At first I thought it was a joke. But no, you really suggest that > everyone who wants to have up-to-date desktop environment > but without few packages (e.g. N-M or GDM) needs to create own package, > own local repository, and looks into it every time there is upgrade > to keep it current? And this is supposed to be simple? Please read the rest of the mail, and the rest of the thread, where I explain that Recommends gets you into the same manual bookeeping situation anyway. Unless, of course, you treat Recommends specially for meta packages... and that is supposed to be simple how exactly? > Do you really think that forcing many people to maintain their > own repositories and metapackages is better than just moving > e.g. N-M or GDM3 from Depends to Recommends? Forcing? No. But it seems, I have to reiterate the solutions that are all superior to downgrading stuff to Recommends: 0) Cherry pick packages by hand === Advantage is obviously that this is the most flexible way. Period. Disadvantage: no easy way to remove everything in one go, and it's a bit of a burden to follow the platform. However, lets consider the average user using stable: how often does the platform change? Zero times during a stable release. Zero. You might have to follow changes during a dist-upgrade, but that, I believe, is acceptable. If you're not using stable, well, tough luck, but you made that choice consciously, and should've been aware of the downsides, which may include a bit of extra work on your part. Still, even in that case, how often does or did the list of Dependencies of the gnome meta-package change since squeeze? I don't expect it'd changed much, save for the gnome2->gnome3 transition, and most of the changes most probably wouldn't need followups anyway. If I'm mistaken, please do correct me, however. 1) Use a custom meta package The advantage here is that it's easy to do, easy to automate, and you can easily follow the upstream meta-package, excluding only a few of its dependencies. The downside is obviously that you (or a script) has to maintain a local repo. Personally, I couldn't care less what the tool that automates this for me accomplishes that, as long as it can be fully automated (it can be), but some may disagree. And it's certainly not the most elegant solution. 2) Use dummy equivs packages Instead of replacing the meta, you'd replace the dependencies you don't want installed. The advantage is that you don't have to maintain a local repo, and you get to use the upstream meta as-is. The downside is that you'll have a bunch of local dummy packages, and you have to make them. Again, that can be scripted, and completely hidden from the user. Nevertheless, this is still not the most elegant solution. 3) Upload a gnome-minimal package or somesuch = The advantage is that it will have whatever you want. The downside is that the maintainer must keep it up to date, and whoever disagrees what constutites minimal, whill continue shouting. Yet, this is straighforward, and places the burden on one person instead of everyone who might want such a package. X) Downgrade stuff to recommends I do not consider this a solution, for reasons explained elsewhere, where my main concern is that it breaks the assumption that installing a platform (in this case, gnome) will install the whole thing, and it will be available for my use at any time. With recommends, there's a fair chance that a distinctly related package forces part of the platform off, and the package manager will happily remove them. Once the breakage is fixed, it will not reinstall them. This can be worked around by removing the auto-installed flag from those parts of the platform that I want to keep at all times, but then what is the use of Recommends, when I have to cherry pick anyway? I could just skip installing the meta, the net effect is the same (except, that without the meta, there are no expectations to break). > Think about all those hours wasted, times however many people who > want to customise their desktops. I still don't see the problem with installing a subset by hand. Advanced users can script it, novices will only need to hand pick once. Done. 10 minutes job. Compare that to the hours wasted trying to figure out what forced part of the platform off my system and when, during an unattended upgrade.. Yes, I do those, because I want to trust the system doing the right thing, and keeping stuff I installed intact and complete. If I have to double-guess the package manager, then there is something seriously wrong. Recommends would force me to do that. -- |8] -- 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/87pq
Re: Recommends for metapackages
Thibaut Paumard writes: > Le 12/07/12 11:06, Gergely Nagy a écrit : >> Lets consider another case! Suppose I have Install-Recommends turned on, >> and install a theoretical meta package, that has half of its stuff in >> recommends, because they're not strictly necessary, but merely enhance >> the system. Lets suppose one of these enhancements include a tool I use >> every once in a while, but not daily. > > A later upgrade to your beloved meta-package could very well drop this > dependency. While that may happen, that is far more unlikely than the case I outlined, and a case I can live with. > If that's a tool that you know you want, I strongly suggest > you mark it as manually installed. Problem is, at the time I installed the meta, I did not know about this particular tool. It came with the platform, and I really do not want to care which part of the platform it is. It came with it, I expect it will stay as long as it is part of the platform. Recommends breaks that assumption. >> As for why I wouldn't notice? Because I trust the system to do the right >> thing, and I do automatic, unattended upgrades. Not an uncommon thing to >> do, I believe. > > You should always check what your package manager wants to remove. Why? In my setup, it will never remove things that are not marked auto-install. I ensure that my system works, by having all dependencies satisfied. (And any recommends or suggests I do need, I install by hand) I do unattended upgrades for a reason: I don't want to spend time on double-guessing something that should work automatically. > In my experience, more often than not, aptitude tries to remove the > full gnome metapackage because of a temporarily unavailable depends. Well, mine won't do that, as I don't have gnome marked auto-install, so it will abort the upgrade instead. However, if things would move down to Recommends, it would happily proceed to remove things I do use, just because I didn't install it by hand... And here we get back to the same issue others had: manual bookkeeping. But this time, with recommends. So pray tell me, how is Recommends any better, when I have to resort to manual bookkeeping anyway? -- |8] -- 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/87ehohthas.fsf@algernon.balabit
Re: Recommends for metapackages
Andreas Tille writes: >> It's a meta-package, that pulls in a platform. If I install it, I want >> the full platform, always. That's about it. If I install mono-complete, >> I want the whole bloody thing, always. > > I think the attempt to ensure something always is not reasonable because > if the admin decided to break the system in whatever way chances are low > that you can do this. And if the admin broke his system, I stop caring. Neither Recommends, nor Depends will help there. > You also can not do this "always" if I as a local > admin do some fancy stuff with preferences to get the dependency > resolution from somewhere else or do some fancy tricks with equivs. So > your always argument is void for other ways to break my machine. Indeed so. But that, too, is outside of the scope. When I say "always", I meant it as "on my system, wearing my root hat". What other people do to their system, is none of my business. > You have intentionally broken your system as it was defined in policy > and you now try one way to fix your personal broken system on all other > systems which are not broken in this specific way. Erm, how have I broken my system? I did not. (Turning Install-Recommends off is definitely not breaking my system, FYI.) > I have not read the whole thread but it seems to me that you have > ignored the system of recommends. Alas, I did not, and I explained it elsewhere in this thread why and how Recommends would break expectations, and why they are inferior to Depends, as far as meta-packages are concerned. I also presented ways to improve the current situation, none of which involve Recommend, and neither would break any system, nor expectations, and as such, are superior to Recommends - at least when talking about meta packages. -- |8] -- 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/87ipdtthm2.fsf@algernon.balabit
Re: Recommends for metapackages
Abou Al Montacir writes: >> As with any package available in Debian: Just don't install it if you do >> not like what the package does! >> >> It really is that simple! > > I think that we really do not have the same understanding of > metapackage. You clearly want them strict and non flexible, I want them > convenient and flexible while ensuring desired functionality. A flexible meta package is useless, however. If you want flexibility, you can already install parts by themselves. If you want to remove them with one broad swipe, that is also possible (create a meta that depends on them all, so they get marked auto-installed, and install that meta; or create a dummy package that conflicts with them, and install that - both of these can be automated, and even beaten into a shape suitable even for novice users, FYI). However, if you want predictability, then Depends is your only option. And if I install a meta package, I expect it to always install the full thing, and keep those parts installed. Something that installs almost the full thing, save a few, and allows distinctly-related stuff to force removal of some of the meta is... well... unpredictable rubbish, that is just asking for trouble. Instead of fighting for Recommends, which would break your system in various interesting ways later on[1], there's a third solution: noone stops anyone from uploading a gnome-minimal package, which depends on gnome-session and a few selected other parts, without n-m. [1]: http://article.gmane.org/gmane.linux.debian.devel.general/174877 And that goes for the rest of the meta packages: you can always introduce more, customized for common needs. So, we could say to users: You don't want the full gnome platform? Neither do you want to pick parts of it by hand? Install gnome-minimal! -- |8] -- 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/87txxdtj9b.fsf@algernon.balabit
Re: Recommends for metapackages
Andrei POPESCU writes: > On Mi, 11 iul 12, 14:41:50, Gergely Nagy wrote: >> Andrei POPESCU writes: >> > >> > Depending on how you do the package selection on your next installation >> > you might end up with rsyslog, but without logrotate[1]. >> >> I don't see how that would break anything. logrotate is not necessary >> for log rotation, not with the syslog daemon of my choice at least. And >> as you said yourself, log rotation isn't mandatory either. > > Given that I have turned off Recommends on that system because it's > space constrained (it's running from a 2GB USB stick) having logs not > rotated would have become a problem eventually. a) logrotate is not required for log rotation. b) You can still install it if you need it. I can also stop installing my video driver, since it's not depended on (nor recommended) by anything but the huge xserver-xorg-video-all metapackage, and then call my system broken. *shrug* -- |8] -- 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/871ukhuyzx.fsf@algernon.balabit
Re: Recommends for metapackages
Steve McIntyre writes: > Gergely wrote: >>Henrique de Moraes Holschuh writes: >> >>> IMO, metapackages should "depend" on the absolutely required stuff (and many >>> times that will be the empty set), "recommend" the rest, and maybe even >>> "suggest" fringe packages. This achieves maximum usability for more >>> usecases, and malfunctions only in the unsupported case of "no install >>> recommends by default" -- you should skip recommends always in a >>> case-by-case basis. >> >>That also achives maximum annoyance, because if I want the full >>platform, I'll have to go recommends/suggest hunting. (No, I'm *not* >>going to turn on install-recommends.) > > Right. So you're arguing that all the packages should be listed as > Depends: to make *your* life easier, when you're doing something > different from what's recommended. Thanks for showing how much weight > we should attach to your argument. It's a meta-package, that pulls in a platform. If I install it, I want the full platform, always. That's about it. If I install mono-complete, I want the whole bloody thing, always. If I install kde-full, I want the full KDE desktop, with all bells and whistles. If I install gnome, I want the whole thing with all strings attached. That's what I consider a meta-package's job. If I want parts of it, I will install parts of it. Metas are a convenience for the most common case: installing all of it. Lets consider another case! Suppose I have Install-Recommends turned on, and install a theoretical meta package, that has half of its stuff in recommends, because they're not strictly necessary, but merely enhance the system. Lets suppose one of these enhancements include a tool I use every once in a while, but not daily. Now, a few months later, a transition comes about, and this package I have gets removed, because another thing I update breaks/conflicts/whatevers it. Since it's a recommends only, my package manager will most likely want to remove it. I now have two options: I either notice this, and stop the upgrade, or I don't and poof, part of the platform's gone. I installed the full thing, and lost part of it. I'm not happy. As for why I wouldn't notice? Because I trust the system to do the right thing, and I do automatic, unattended upgrades. Not an uncommon thing to do, I believe. But with recommends, the system failed me here, and removed part of the platform that I *explicitly* installed. And I had Install-Recommends turned on. Thank you, I'd rather have Depends, and a reliable way to keep the full platform on my system. Would I want to remove parts of it, I already have the power to do that with the status quo. I can even keep up with the meta package easily, if I choose to do so. I don't know about you, but I prefer my systems reliable and I absolutely hate when it wants to screw me over and try to remove parts of stuff I explicitly asked it to install. -- |8] -- 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/87629tuz4v.fsf@algernon.balabit
Re: Recommends for metapackages
"Eugene V. Lyubimkin" writes: > On 2012-07-11 14:33, Gergely Nagy wrote: >> "Eugene V. Lyubimkin" writes: >> >> > Moreover, despite me understanding the picture, I still >> > has no clean, safe and documented way to do what I'd want in case the >> > package maintainer chosed Depends. >> >> You have: install the pieces you want by hand. That's at least clean and >> safe. I do not think it is worth documenting explicitly. > > No, this is (IMO) not a solution: [1] Script it. I believe those who are unhappy with n-m, and understand what Depends and Recommends do, are able to write 20 lines of shell. I already posted at least one solution for the problem: https://lists.debian.org/debian-devel/2012/07/msg00219.html >> [...] Demoting to Recommends would be >> less so, but if upstream considers a package a core part of a platform, >> recommends *is* wrong. If you disagree with upstream, you have the tools >> and the ability to customize your system: use a non-stock meta package. > > Well, disagreed here. By the logic above we, for example, cannot apply > any patches NACKed by upstream. That's not nearly the same thing. >> It's not hard. I'd be very curious why you're so against it, perhaps we >> can come up with a solution that satisfies you? > > Because if a user who installed Debian yesterday asks me "So how do I do > that?" I want my answer to be > > "It's easy, just do '$packagemanager remove $singlepackage'" > > instead of > > "It's easy, just build and maintain a non-stock meta package" How about: "Install $this package, and run $that command, answer its questions, and you're done!" That would: - Allow us to keep Depends as Depends - Allow users who wish to follow the meta, with parts of it removed to do so, conveniently. - Leave everyone else unaffected. Which, in turns means: - People happy with the status quo remain happy - People unhappy with have an easy, convenient solution that anyone can use without knowing a thing about meta packages or building packages or anything like it. A solution you could point a novice user to, and said user would be happy with it. Said package takes half an hour to make, perhaps another half to make it friendly. Those caring enough, could've solved the issue by now. Since there was nothing done but useless throwing of words, I'd think noone cares enough. -- |8] -- 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/87d341uzsa.fsf@algernon.balabit
Re: Recommends for metapackages
Noel David Torres Taño writes: >> Yet, we try to not diverge much from upstream, and maintain a good >> relationship with them. If they consider it core, so can we. Those who >> want to hand-pick parts of a meta package, can do so, we do not forbid. > > If we want to be user friendly, it is not a matter of "we do not forbid", it > is a matter of "we make easy". Besides, low-level users will install > Recommends by default, so they will get the whole box anyway. But medium or > high level users may probably want N-M not to mess their network EVEN if they > want the whole gnome desktop set. >> >> I do not see the problem: those who want the full platform, can get it >> easily. Those who don't, and want to exclude some, they can do so easily >> too. A bit more work, but hey, if you're going to cherry pick, that will >> always involve more work. >> >> The amount of extra work necessary is minimal though. > > Not so minimal if you want your gnome set to be up to date, including new > applications being installed. It is very minimal. 5 minutes of work. Been there, done that, posted the bulk of the solution, and a general outline of the rest of it to this list, in this very thread, multiple times. Please take some time to read it. But alas, I'll make it easy for you: If you want to install a meta-package, but without one of its dependencies, and want to keep up to date with it too, so you get all the new stuff added to it, and you also want to be able to remove the whole thing with one swift sweep, here's what you do: - Grab the control file of the meta-package (~1 line in shell, use grep-aptavail) - Filter out unwanted packages from depends (~5-6 lines in shell) - Create a local package, under a different name, with the updated information (~10-20 lines, use equivs) === 5 minutes so far === - Push it into a local repository (~2-3 lines, use whatever, reprepro, mini-dinstall, or cat < What we should do is to allow TWO levels of cherry-picking: the one for > advanced users who want to individually select every package, and the other > for users who want the whole set without a specific, molesting package. We already have the first, it's called installing by hand. The second can easily be done, see above. > If that package is not a true dependency of the core of the set, > Recommends is more than justified. Upstream considers it a dependency in this case, part of a platform. If you don't want the full platform, don't install the full one, select the pieces you need - it is that easy. Similarly, if you don't want to install a full blown desktop system with a GUI, you don't select the desktop task when installing Debian. If you do want some little things later, you install those by hand. In case of gnome, the package pulls together what upstream considers the GNOME platform - it is that simple. If you don't need it all, don't install it all. If you want to follow the platform, but skip parts of it, I already presented two solutions above. You're welcome. -- |8] -- 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/87hatdv0dm.fsf@algernon.balabit
Re: Recommends for metapackages
Thibaut Paumard writes: >> That also achives maximum annoyance, because if I want the full >> platform, I'll have to go recommends/suggest hunting. (No, I'm >> *not* going to turn on install-recommends.) > > You don't want to turn on install-recommends, but you are happy with > installing a loaded meta-package such as "gnome" or "kde-full"? I am happy with installing gnome, because I (or my parents, in case of my desktop) use pretty much all of it from time to time. Would I find something in it that I never use, and would it eat enough space or other resources to annoy me, I'd do my own local meta-package instead, that wouldn't have the unnecessary parts. The reason I do not turn on install-recommends, is because in the vast majority of cases, I do not need the recommended packages. Removing them by hand is much more work than installing the few that I do need. This isn't the case for the gnome meta-package. As for kde-full: no, I'd never install it. There's one kde thing I use, kcachegrind, and I'm happy to install that by hand. Would I be a kde user, I would probably not install kde-full either, because - by the looks of it - there would be significant parts of it that I'll never use. That doesn't mean it should only recommend them, no need to, I'm perfectly capable of installing the subset I need. I am also perfectly capable of writing a script to notify me whenever the meta-package's dependencys change, so I will have the option to pull in new things if I want to. (Said script is ~10 lines, and I wrote it yesterday in about 5 minutes; less time than I spent replying to this mail.) >>> OTOH, metapackages from hell (like gnome or kde-full) based on >>> Depends require me to select them, go to the "will install these" >>> screen, deselect the meta package, and go over the list manually >>> installing whatever isn't going to be useless/unwelcome for my >>> specific case. And I will never notice if the metapackage >>> changes its dependency tree later on. >> >> You could script all that, and keep your local list up-to-date >> with about ~10 minutes of work. > > The annoyance of not being able to uninstall just one of many packages > pulled by a big meta-package does not affect only developers. A > reasonable solution should be found which works for our priority: our > users. Like I said earlier: script it. I posted a script that can remove any number of packages from another's depends line, and echo a control file. Updating that to create a local meta-package is a piece of cake. Hooking it into apt is also similarly easy, and bingo, you have a solution. Package it up, create a config file for it, and it's ready to be shipped to users. Everyone wins. The whole thing is about an hour of work with everything included for anyone who cares enough, far less than the time already spent arguing about silly things on this list. -- |8] -- 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/87fw8ywhyf.fsf@algernon.balabit
Re: Recommends for metapackages
Noel David Torres Taño writes: >> Well, in case of GNOME, upstream considers n-m to be part of the core >> system, to the best of my knowledge. If upstream does so, so should we. > > No. That's why we have our own distribution instead of just a collection of > unpatched packages compiled from source. > > Debian patches do not only include security or functionality bugs. They > include also design bugs. Yet, we try to not diverge much from upstream, and maintain a good relationship with them. If they consider it core, so can we. Those who want to hand-pick parts of a meta package, can do so, we do not forbid. I do not see the problem: those who want the full platform, can get it easily. Those who don't, and want to exclude some, they can do so easily too. A bit more work, but hey, if you're going to cherry pick, that will always involve more work. The amount of extra work necessary is minimal though. -- |8] -- 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/87r4siwjn4.fsf@algernon.balabit
Re: Recommends for metapackages
Andrei POPESCU writes: > On Ma, 10 iul 12, 18:43:03, Gergely Nagy wrote: >> >> During the past ~14 years I've been using Debian with that setting >> turned off, nothing ever broke on my systems because of this setting. If >> it does, then I'll consider that a bug and report it appropriately. > > Depending on how you do the package selection on your next installation > you might end up with rsyslog, but without logrotate[1]. I don't see how that would break anything. logrotate is not necessary for log rotation, not with the syslog daemon of my choice at least. And as you said yourself, log rotation isn't mandatory either. -- |8] -- 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/87vchuwju9.fsf@algernon.balabit
Re: Recommends for metapackages
Henrique de Moraes Holschuh writes: > IMO, metapackages should "depend" on the absolutely required stuff (and many > times that will be the empty set), "recommend" the rest, and maybe even > "suggest" fringe packages. This achieves maximum usability for more > usecases, and malfunctions only in the unsupported case of "no install > recommends by default" -- you should skip recommends always in a > case-by-case basis. That also achives maximum annoyance, because if I want the full platform, I'll have to go recommends/suggest hunting. (No, I'm *not* going to turn on install-recommends.) > OTOH, metapackages from hell (like gnome or kde-full) based on Depends > require me to select them, go to the "will install these" screen, deselect > the meta package, and go over the list manually installing whatever isn't > going to be useless/unwelcome for my specific case. And I will never notice > if the metapackage changes its dependency tree later on. You could script all that, and keep your local list up-to-date with about ~10 minutes of work. -- |8] -- 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/87zk76wk3o.fsf@algernon.balabit
Re: Recommends for metapackages
"Eugene V. Lyubimkin" writes: > Moreover, despite me understanding the picture, I still > has no clean, safe and documented way to do what I'd want in case the > package maintainer chosed Depends. You have: install the pieces you want by hand. That's at least clean and safe. I do not think it is worth documenting explicitly. >> > Using Recommends for non-core parts of >> > metapackages' dependencies would nicely solve that. >> >> ...but I disagree that making meta-packages more elastic is a "nice" >> solution: is a hack covering over misguided users. Possible solutions >> could be improved documentation and improved design of package managers. > > ... And I disagree with that. No solution can override policy's "all > Depends must be satisfied". If one choose to support the "exclude from > metapackage" one either has to change the policy, remove packages from > Depends or use non-stock metapackage (which I personally don't like). Changing the policy would be stupid. Demoting to Recommends would be less so, but if upstream considers a package a core part of a platform, recommends *is* wrong. If you disagree with upstream, you have the tools and the ability to customize your system: use a non-stock meta package. It's not hard. I'd be very curious why you're so against it, perhaps we can come up with a solution that satisfies you? -- |8] -- 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/874npexyso.fsf@algernon.balabit
Re: Recommends for metapackages
Nikolaus Rath writes: > Gergely Nagy writes: >> For the cases where one wants to have most of the stuff installed that >> the meta-package would pull in, but not all, solutions already exist. > > What solutions do you mean? Installing the pieces one wants by hand, for one. Automating that with a custom meta-package as another, using my script for the automation as a third. Using equivs to create a dummy stub for the unwanted packages (eg, n-m) and using the meta package as-is as a fourth. There are probably other, similarly straightforward options, but four's enough for a start. -- |8] -- 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/87liir4dsk@luthien.mhp
Re: Recommends for metapackages
Nikolaus Rath writes: > Gergely Nagy writes: >> But, to cut the story short, attached to this mail is a script you can >> use to take any metapackage, and remove (or demote) any of its >> dependencies. It echoes a control-file thingy, combining it with equivs >> is left as an excercise to the reader. > > If I'm not mistaken, that means that the demoted dependency will get > pulled in again on the next upgrade of the metapackage, or that I have > to put the metapackage on hold and will loose any demotions and > promotions of other packages in future metapackage versions. No, you name the local meta package differently. No need to put it on hold or anything. If you want to follow the original meta, set things up so that the local gets updated once in a while. That's doable with an Apt::Update::Post-Invoke hook, as I believe I said in the mail above. -- |8] -- 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/87pq834dva@luthien.mhp
Re: Recommends for metapackages
Sune Vuorela writes: > On 2012-07-10, Gergely Nagy wrote: >> No. Only if installing recommends is turned on, which cannot be >> guaranteed. > > There is many ways to break your system. turning off installation of > recommends is one of them. During the past ~14 years I've been using Debian with that setting turned off, nothing ever broke on my systems because of this setting. If it does, then I'll consider that a bug and report it appropriately. -- |8] -- 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/87wr2by3c8.fsf@algernon.balabit
Re: Recommends for metapackages
"Eugene V. Lyubimkin" writes: > On 2012-07-10 18:10, Jonas Smedegaard wrote: >> The very purpose of a meta-package is to _ensure_ that a certain set of >> packages is installed, not just recommend them: All (not only most) >> users of that package need all its dependencies satisfied > > My definition of meta-package is less strict than yours. I as user > sometimes want '[meta]package X, but without packages Y and Z', and your > definition absolutely rules that out. That's not a meta package then. That's a collection of loosely coupled stuff, and by that definition, a meta package should not use depends at all, but always recommends, because someone may want to use metapackage X, but without A, B and C. Might aswell get rid of them then. > I saw many questions on forums like > > "I did '$packagemanager install $metapackage' and then after > '$packagemanager remove $singlepackage', why $packagemanager now wants > to remove all $metapackage?" > > , so I know I'm not alone. Using Recommends for non-core parts of > metapackages' dependencies would nicely solve that. Well, in case of GNOME, upstream considers n-m to be part of the core system, to the best of my knowledge. If upstream does so, so should we. Besides, the solution is very easy: don't want all the deps of the meta? Don't install it. If you still want to pull most in, but exclude some, see the script I posted earlier. It can easily be changed to echo an apt-get line instead of a modified control file, if that's more suitable. -- |8] -- 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/874npfzi3e.fsf@algernon.balabit
Re: Recommends for metapackages
"Eugene V. Lyubimkin" writes:
> On 2012-07-10 16:18, Gergely Nagy wrote:
>> But the purpose of the meta-package is to pull stuff in. Depends does
>> that, Recommends does not, therefore Recommends is not appropriate for
>> the task.
>
> Surely Recommends does pull stuff in.
No. Only if installing recommends is turned on, which cannot be
guaranteed.
> It's clearly reflected in Debian policy
No, it is not.
"Recommends
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found together
with this one in all but unusual installations."
Nowhere does that say that whatever is in recommends, will be
installed. Therefore, tools will *not* pull those in, unless they are
asked to.
> and supported by most if not all high-level packages managers in
> Debian.
Yes, apt and aptitude supports Apt::Install-Recommends, and it is
enabled by default. But it can - and often is - turned off.
> Therefore it's totally appropriate for the task.
It is not, because the purpose of the meta package is to get things
installed *always*. If it would be an optional collection of stuff, it
wouldn't be a meta package.
But, to cut the story short, attached to this mail is a script you can
use to take any metapackage, and remove (or demote) any of its
dependencies. It echoes a control-file thingy, combining it with equivs
is left as an excercise to the reader.
Usage:
$ ./meta-gen.sh gnome-core network-manager-gnome
Build a local package out of that, use happily ever after. Our
meta-packages can continue depending on what upstream considers part of
a package suite, and those of you who want to have most, but not all of
it, can use the script to create a local meta package. Since it's
scripted, you can even keep the local thing reasonably up to date.
It took about ~5 minutes to write that script, would take another 10 or
so to make it build a local package too. I'm fairly sure this could be
hooked into apt via a Apt::Update::Post-Invoke: once apt-get update ran,
update the local meta packages, push it to a local repo, touch a stamp
file, and update again. But perhaps there's even a way to make this play
nicer, I didn't care that much.
Crude, but should work, with about ~20 minutes of total time spent on
it. Much less than pointless arguing on a list about something that's so
very easy to solve in a way that everyone wins.
--
|8]
#! /bin/sh
set -e
pkg="$1"
shift
dropdeps=",$(echo $@ | sed -e 's# #,#g'),"
if [ -z "${pkg}" ]; then
cat <
Re: Recommends for metapackages
"Eugene V. Lyubimkin" writes: > On 2012-07-10 15:32, Josselin Mouette wrote: >> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : >> > What's wrong with Recommends: in that case? It seems to perfectly >> > match the "makes life easier for > > XXX>" scenario you describe. >> >> Recommends is wrong for metapackages because it gets upgrades very >> wrong. This is why it is used very marginally. > > Standards should not depend on implementation details. I see zero > reasons why metapackages are (or should be) specific here. Whatever $it > that gets upgrades wrong should be fixed instead. But the purpose of the meta-package is to pull stuff in. Depends does that, Recommends does not, therefore Recommends is not appropriate for the task. For the cases where one wants to have most of the stuff installed that the meta-package would pull in, but not all, solutions already exist. And like Josselin said in the same mail, there is a large overlap between those who want to push some of the stuff in Depends to Recommends, and those who can just make their own local meta-package within 5 minutes and be done with it. -- |8] -- 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/87obnnzoly.fsf@algernon.balabit
Re: Clarification on the Origin: field in the Patch Tagging Guidelines?
"Theodore Ts'o" writes: > P.S. One of the things I'm thinking about doing is writing a script which > automatically generates the debian/patches directory from the git > repository. So when I specify the base release (i.e., v1.42.4), it will > do something like git format-patch, but in a debian/patches Quilt 3.0 > format. That way I don't have to replicate the patches twice in my git > tree (once as the real commit, and once in the commits which create the > debian/patches/* files). FYI, gitpkg can do that, among other things, git-buildpackage's gbp-pq can do something similar aswell. So the script you wish for already exists, and is packaged. ;) -- |8] -- 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/87pq90r8m2@luthien.mhp
Re: [RFC] Add upstream VCS info to control file
Ansgar Burchardt writes: > On 06/15/2012 11:33 AM, Thomas Goirand wrote: >> Yeah, a hook of any sorts is ok for me. The get-vcs-source in debian/rules >> seems quite ok to me. Should debcheckout be modified to call it? It's part >> of devscript, do you think it's ok if I submit a wishlist bug report against >> devscript to ask for such feature? > > No, running code from a repository during checkout is a bad idea. As you mentioned on IRC: cover the common cases with something machine-readable, and make it able to point people to d/rules get-vcs-source if it detects that extra work needs to be done? (This could be as easy as a flag in said machine-readable place) This way we get the best of both worlds. -- |8] -- 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/87vcisrhfy@luthien.mhp
Re: [RFC] Add upstream VCS info to control file
Thomas Goirand writes: > On 06/15/2012 12:03 AM, Cyril Brulebois wrote: >> Anyway, here's what I've been doing for our 150+ X packages: >> >> $ cat xserver-xorg-video-ati.git/debian/watch >> #git=git://anongit.freedesktop.org/xorg/driver/xf86-video-ati >> version=3 >> http://xorg.freedesktop.org/releases/individual/driver/ >> xf86-video-ati-(.*)\.tar\.gz >> >> debcheckout gives you a debian-unstable branch by default. Then calling >> the tiny xsf-remote-add-upstream script gets the watch file parsed, and >> the upstream branch added: >> >> http://anonscm.debian.org/gitweb/?p=pkg-xorg/debian/xsf-tools.git;a=blob;f=xsf-remote-add-upstream >> > > That's really cool, but what would be even cooler would be something > standardized in Debian, so that we all do the same way. Probably > having your something like your xfs-remote-add-upstream script, but > built in debcheckout, git-buildpackage or something like that. > > Now that you tell about it, I agree that adding yet another field in > debian/control was short sighted. While having a standardized way would be useful, there's just so many workflows, that you can't possibly cover all of them with a single syntax, and in the end, you'd end up with having to call package-specific scripts in the source. We already have Vcs-*, to check out the debian branch. If debian/rules would have an optional target, similar to get-orig-source, that would finish checking out the repository, grabbing upstream stuff, and setting up branches too, that would solve your problem. debcheckout could be extended to check whether the target exists, and call it too, so in the end, you'd end up with using a single command, that gets you what you want. And we didn't attempt to cover every different case with a single syntax in debian/control, or another file. Call this target get-vcs-source or similar, and voila! -- |8] -- 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/87boklrun1@luthien.mhp
Re: [RFC] Add upstream VCS info to control file
Gregor Jasny writes: > When one tries to fix a FTBFS bug a look into the upstream VCS is > often helpful. Sometimes a link to browse them is easily found on the > homepage linked from the PTS page. But often these links are deeply > buried in the linked website. > > What I'd like to see in the Debian control file are Vcs-Upstream > fields that work like their Vcs- pendents but point to the upstream > sources. These URLs would also be linked in the PTS. > > Does this sound reasonable? I'd rather put it in debian/README.source, I see no need of shoveling yet more fields into debian/control. (Yeah, yeah, having it there would make it possible to do debheckout --upstream or similar, but.. that would be rarely needed enough to use README.source instead). -- |8] -- 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/87lijqowly.fsf@algernon.balabit
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
Ian Jackson writes: > So for example, DDs have enormous theoretical power but there are > strong and well documented social controls on how they should exercise > that. I think as a matter of principle that the same principle should > apply to DMs: it is easy to remove a misbehaving DM from Uploaders. For some values of easy. It requires a sourceful upload for possibly no other reason than to remove an uploader. That's a waste of time, not only for the maintainers, but the buildds and archive software too. Would the package take long to compile, it would be even worse. We can't compare this to the case of DD's, because DD upload rights are only governed by social customs and the keyring, the DMs have *additional* restrictions, which currently are tied to the source package. > So it is not necessary to have technical measures that prevent a DM > mentioned in Uploaders from violating the package's uploading rules, > bypassing review processes, or whatever. Instead, when a package team > or lead maintainer accepts someone into Uploaders we should clearly > communicate to the new uploader what is expected of them, and then we > should trust them to do as we have asked. Well, one of the reasons DMs are not DDs, is because they do not have the same rights as DDs do: they can't, and in my opinion, shouldn't be able to upload pretty much any package without further restrictions. If they would, they'd technically have the same upload rights as DDs do, with a fraction of the experience, and without going through NM. I don't think that would be wise. (No disprespect meant for DMs, mind you) However, this (whether we need the extra upload restrictions for DMs), I believe is not strictly related to the proposal, which, to my reading, was more about moving the DM-Allowed field out of the source package, and a few other things. > The questions that need to be answered for a package are: [..] > * Who makes final decisions about the package; this includes >arbitraring disputes, delegating authority, revoking such >delegation, etc. [...] >I'm going to call these people the maintainers of the package. >They might be DDs, DMs, or contributors without a key in the >keyring. > >Currently this information is sometimes in the Maintainer field; >sometimes in both the Uploaders and Maintainers fields; and >sometimes somewhere else completely (eg a team wiki page). > >Normally the maintainers would be the people who are doing most of >the work. Sometimes we have provisional maintainers who are >neither DD or DM; in those cases the maintainer works under the >supervision of their sponsors. So far, I agree. > c. Who is entitled to prepare a non-NMU upload of the package. > >This information needs to be accessible to the project as a whole. > >Particularly a potential drive-by sponsor needs to know whether the >upload they are sponsoring is by someone entitled to prepare such >an upload. And the archive software needs to know whether to >permit an upload. > >Currently this information is sometimes in the Maintainer field; >sometimes in both the Uploaders and Maintainers fields; and >sometimes somewhere else completely (eg a team wiki page). There's also the case of DM-Allowed: yes. If someone is listed as maintainer, but is not a DD, then my understanding is, that he is not entitled to upload. (Hence, should not be in Uploaders, either, unless DM-Allowed: yes is set) This looks silly, though, and inconsistent, and very easy to miss when sponsoring or working within a larger team. Nevertheless, in case the maintainer is not a DD, he either needs a sponsor, or must be a DM, with the package having DM-Allowed: yes. This also presents a problem when adopting packages, because if the adopter is a DM, someone must sponsor his first upload or set DM-Allowed: yes otherwise in a separate upload - neither of which is particularly friendly towards the DM (nor anyone else, really). Would this restriction get untied from the source, the former maintainer could grant upload rights without having to do a sourceful upload, and everyone wins, and no rights get harmed either. > e. What process should someone preparing a non-NMU upload follow? > >Eg, is there a VCS that everything should be committed to ? Are >non-emergency uploads supposed to be reviewed somewhere ? Are some >of the people who are entitled to upload supposed only to do so >after explicit indication by someone more senior that they should >do so ? > >Again this information doesn't generally need to be available to >people outside the packaging team. However, if there are >significant and important processes that should be followed, a >drive-by sponsor should be able to find them easily so that they >can double-check that the person preparing the upload (the sponsee) >seems to be doing the right thing. > >Currently this information is, if
Re: Planned changes to Debian Maintainer uploads
Bernd Zeimetz writes: > Which bad things happened that we have to change the current process? As far as I see, it's more about "what good things didn't happen" why we have to change the process. That is also addresses a few corner cases that could've gone bad, but never did is a side-effect. -- |8] -- 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/87y5nssmbn.fsf@algernon.balabit
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
Thomas Goirand writes: > By the way, do other think that, even in this case, I should keep the > changes > as minimum as possible? Or is it ok, considering that all of our > toolsets have > changed since the last upload (eg: we now have pkg-php-tools and dh 8 > sequencer), that we do a bit more changes in the package than just the new > upstream release? Since the package has been unmaintained for years, and from what I've read so far, it does seem that it will end up under a team's umbrella anyway in a month's time, I wouldn't care about any possibly hurt feelings, and update the packaging to current practice. Quality and maintainability should come before the letter of any NMU recommendations and best practices. -- |8] -- 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/878vg9eopq.fsf@algernon.balabit
Re: What to do with bug reports against non-existing/removed packages
"Daniel Leidert" writes: > Hi, > > Our bug tracker contains items for packages, which do (not longer) > exist. What should happen to them? I see, that it might be a good idea > to keep them for the case, a package is re-introduced. But this might > happen only for a few packages. Most of them got removed because newer > versions were released. What about closing those reports, if an > RM-request is filed? This is a hard task, as there's no simple set of rules that would apply to all bugs. Some were filed against packages that existed at a time, but got removed without the bug being closed (this often happens when the source remains, it just stops building a particular binary package). In this case, the bug should be examined, and either reassigned if it still applies, or closed (preferably with a version) if it does not. Then there are the case of misfiled bugs: bugs filed against packages that never existed, but were installed from a third party repository (these should be closed with an appropriate message, urging the submitter to either contact the third party repo's maintainer, or upstream, whichever is more applicable); typos in package names, where a reapply would be best; bugs against packages not yet in the archive (but either in NEW, or in the archive, but so fresh its not known to the BTS yet): these should be left alone most of the time, but in certain cases, it might be a good idea to contact the maintainer, so he'll know about these reports, as the BTS will not notify him when the package enters the archive. If he doesn't check the BTS page, but relies on email, he won't know about the reports. There are probably a few other corner cases, but as you can see, it's not simple. That's why the list is so long still. On and off, a few people (myself included) try to shorten a bit, and so far, it seems we can handle the newly misfiled bugs. Any help with getting the backlog down to a much smaller number would be greatly appreciated. Updating the wiki[1] with guidelines and HOWTOs on how to handle specific cases would also be desirable, and I'm happy to help with either. [1]: http://wiki.debian.org/Teams/unknown-package/TODO -- |8] -- 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/87mx55n5ho.fsf@algernon.balabit
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Chris Knadle writes: > On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote: >> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote: >> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: >> > > No, I hereby start saying good by to 3.0 >> > >> > I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also >> > found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last >> > few packages. >> >> I can't see any reason to use 1.0 anymore, ever. >> >> It is true that 3.0 (quilt) does have a great downside, quilt, but it also >> has a number of upsides. And working around quilt is simple: >> >> echo "single-debian-patch" >debian/source/options >> echo "/.pc" >>.gitignore >> echo "/debian/patches" >>.gitignore > > I'm confused concerning the above; the point of a VCS in this context is to > track changes to the source package, and the patches are themselves important > changes to the source package. If you have Git ignore the patches then Git > doesn't have a complete view of the source package anymore. Why would you > want to do that? Git does have a complete view. What the above does, is tell dpkg-source to fold any changes made to the upstream sources into a single patch. Since the git tree already has the patches applied (with upstream sources on a different branch, most probably), it has a full view. This basically folds whatever patches the git tree has over upstream, outside of debian/ into a single file. That's about it. Since that file is generated, it has no business staying in git. >> Except for nuking upstream debian/ dir which can mean a bit of lost work if >> the upstream is sane (and can save some if they're not), the 3.0 format is >> strictly better than 1.0. > > If debian/ is nuked then so is debian/patches, and if Git has been told to > ignore debian/patches then it cannot bring those files back. You're misreading this. "Nuking upstream debian/" means ignoring any debian/ directory upstream may have had. That is generally a Good Thing(tm), as we want to have our own packaging. The original is still available in both the upstream tarball, and the upstream branch. debian/patches in this case is irrelevant, as that is automatically generated by diffing the upstream tree against the current (git) tree and folding it into a single patch file. > Patching the source can be an effort especially concerning documenting > why the patches were done and the source of the patches, so these seem > like they'd be important to track rather than something to ignore. The reasons can - and should be - documented in git. Granted, that does not transfer to the debianized source package, which is unfortunate, but it's still better than fighting with integrating quilt with a VCS (in which case, everyone with a higher number of patches would go back to 1.0 and custom patching systems and ignore every other benefit of 3.0, because quilt and VCS generally don't play nice together). -- |8] -- 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/871umioo6l.fsf@algernon.balabit
Re: RFC: OpenRC as Init System for Debian
Josselin Mouette writes: > Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit : >> > There is a huge difference between gconf, for which you can set one >> > specific setting in /etc, overriding the default in /usr (and in a way >> > that will not break the application if the schemas change), and >> > systemd/udev, which require to copy the *entire* file, leaving behind >> > any improvements that could made to it in ulterior versions. >> >> Not entirely true. You can override parts of the file too, without >> copying: include the original. This doesn't let you override everything, >> but for a lot of things, is good enough. > > And then, when the original file changes, you lose the improvements and > you might even end up with a broken system. > > For example if a systemd unit file is updated to match a change of > behavior in a daemon. Say, from now it requires a pre-exec stanza to do > stuff it used to do at startup. Your modified file in /etc will not > include this new stanza and your daemon is broken. Same problem exists with conf.d/ snippets. It's nothing unique to systemd, nor to etc-overrides-lib. If you can override, include or otherwise configure your system in such a way that you do not get warned when one part changes incompatibly, it will likely break, indeed. That is what NEWS.Debian can be used for, for example. But in systemd's case, there are better options, as discussed in this thread elsewhere (and from what I've been told, with a little bit of postinst magic, this can easily become a non-issue, but I haven't tested that yet). -- |8] -- 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/87ipfwphgs.fsf@algernon.balabit
