Hello,
On Sun, Sep 07, 2014 at 12:51:53PM +0200, Jakub Wilk wrote:
> * Paul Wise , 2014-09-07, 17:38:
> >>We should probably also monitor package conflicts. We made a big fuss
> >>about node vs nodejs (and rightly so); but I bet that we have lots of
> >>other package pairs in the archive that can'
* Paul Wise , 2014-09-07, 17:38:
We should probably also monitor package conflicts. We made a big fuss
about node vs nodejs (and rightly so); but I bet that we have lots of
other package pairs in the archive that can't be co-installed for no
good reason.
We have this already:
https://bugs.de
On Sun, Sep 7, 2014 at 6:36 PM, Johannes Schauer wrote:
> would it make sense to extend this test and not only check whether packages
> that share a file listed in Contents.gz can be co-installed but also packages
> which access/change/create the same files in their pre/post-install maintainer
> s
Hi,
Quoting Paul Wise (2014-09-07 11:38:27)
> On Fri, Sep 5, 2014 at 3:35 AM, Jakub Wilk wrote:
>
> > We should probably also monitor package conflicts. We made a big fuss about
> > node vs nodejs (and rightly so); but I bet that we have lots of other
> > package pairs in the archive that can't b
On Fri, Sep 5, 2014 at 3:35 AM, Jakub Wilk wrote:
> We should probably also monitor package conflicts. We made a big fuss about
> node vs nodejs (and rightly so); but I bet that we have lots of other
> package pairs in the archive that can't be co-installed for no good reason.
We have this alread
* Russ Allbery , 2014-08-31, 09:08:
If we want, as a project, to monitor the size of the required,
important, and standard sets, I feel like we should do that directly:
run a cron job somewhere that remembers the previous size, calculates
the new transitive closure, and mails out a report once
6 matches
Mail list logo
