Re: Keeping content of binary and source packages in UDD (Was: Search for a file in all Debian source packages)

[Andreas Tille]

On Fri, Oct 01, 2010 at 08:45:34AM +0200, Andreas Tille wrote:
> On Thu, Sep 30, 2010 at 06:13:45PM -0500, Raphael Geissert wrote:
> > > I *think*, if Raphael hadn't stepped up first and saved you the bother,
> > > you could probably get this information out of UDD.
> > 
> > AFAIK (and supported by [1]) UDD doesn't even have the Contents of binary 
> > packages.
> 
> But in principle it does sound like a good idea to feed this information
> into UDD.  What do you think about keeping content of binary and source
> packages inside UDD?

With content I mean file names (not the content of the files).

Kind regards

  Andreas.

-- 
http://fam-tille.de


-- 
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/20101001065138.gb16...@an3as.eu

Keeping content of binary and source packages in UDD (Was: Search for a file in all Debian source packages)

[Andreas Tille]

On Thu, Sep 30, 2010 at 06:13:45PM -0500, Raphael Geissert wrote:
> > I *think*, if Raphael hadn't stepped up first and saved you the bother,
> > you could probably get this information out of UDD.
> 
> AFAIK (and supported by [1]) UDD doesn't even have the Contents of binary 
> packages.

But in principle it does sound like a good idea to feed this information
into UDD.  What do you think about keeping content of binary and source
packages inside UDD?

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
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/20101001064534.ga16...@an3as.eu

Re: Search for a file in all Debian source packages

[Raphael Geissert]

Jon Dowland wrote:

> I *think*, if Raphael hadn't stepped up first and saved you the bother,
> you could probably get this information out of UDD.

AFAIK (and supported by [1]) UDD doesn't even have the Contents of binary 
packages.

The only other alternative (but there's no guarantee that all the source 
packages in Debian are indexed there) is Google's codesearch[2] - and it may 
not be the right solution either.

[1]http://udd.debian.org/schema/udd.html
[2]http://google.com/codesearch

-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/i835if$62...@dough.gmane.org

Re: data.debian.org -- requirements for packages

[Peter Samuelson]

[Yaroslav Halchenko]
> for HUGE DBs with frequent updates -- may be we could come up with data
> package chains -- i.e. with some base package version + sequence of
> dependent packages with binary deltas which get applied upon
> installation? e.g.
> 
> data-blob-1.0.0
> data-blob-1.0.0+1
> data-blob-1.0.0+2

Sounds like you want a dpkg mode where you can pre-depend on a prior
version of your own package, and _not_ delete files that are shipped by
the base package that are not shipped by the 'delta deb'.  Because of
this pre-dependency, you would not be able to install this deb as a new
install, it would have to be an upgrade.

Tool support for being able to install a base deb in order to install
an updated deb would be pretty hairy, I expect, as would infrastructure
support for providing both in the same Packages file.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
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/20100930215214.ga3...@p12n.org

Re: Debian ppa

[Jon Dowland]

On Thu, Sep 23, 2010 at 06:53:02PM +1000, William Grant wrote:
> Well, those few sysadmins manage Launchpad, Landscape, Ubuntu One and
> some other internal applications. And you wouldn't want or need to run
> all of Launchpad's services.

Well that's interesting.  The point I was going to make before I read this para
was, the problem with running a copy of LP is getting all those other services
(bugs etc.) which we don't need - in fact, most likely, actively don't want, to
avoid diluting our existing services.  Would installing and maintaining a copy
of LP with everything but PPA functionality switched off really be easier than
bolting PPA onto the existing Debian infrastructure? (an open question I 
suppose)


-- 
Jon Dowland


-- 
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/20100930215123.gc1...@deckard.alcopop.org

Re: Debian ppa

[Jon Dowland]

On Thu, Sep 23, 2010 at 07:17:22AM +0200, Marc 'HE' Brockschmidt wrote:
> Actually, the proposed project [1] also included work on the dak side

I read that as "dark side"... but the effect was just the same ;)


-- 
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/20100930214730.gb1...@deckard.alcopop.org

Re: Debian source code search engine

[Peter De Wachter]

Op Thu, 30 Sep 2010 16:07:14 -0400
schreef Yaroslav Halchenko :

> Following Michael's inquiry  I finally found this thread.
> 
> Peter, are there any plans to make Debian's source code indexer alive
> again (and may be placed on somewhat permanent/reliable hosting)?

Unfortunately I can't host it anymore. I've put the site's code
online (http://github.com/pdewacht/source.debian.net) in the hope that
somebody else could, but it's not something you can put on a standard
hosting account.

The system requirements are about 200gb disk space and the more RAM the
merrier. On my old server (I don't recall the exact specs but it was a
fairly beefy system), re-indexing took about 6 hours for a typical
update. During that time the server was pretty much unusable for
anything else. I'm guessing that will be much better if you could put
the indices on an SSD.

The scripts actually don't do anything very complex, it's
basically an opengrok config file and a script to maintain an
uncompressed tree of the current Debian source. I didn't try to archive
historic versions of packages, or do things like expanding tarballs in
source package (I was hoping OpenGrok would learn how to search inside
tarballs, but it still doesn't do that).



signature.asc
Description: PGP signature

Re: Summary of CUT discussions

[Marc Haber]

On Wed, 29 Sep 2010 18:05:24 +0100, Darren Salt
 wrote:
>I demand that Roland Mas may or may not have written...
>> And if I may join the bikeshedding, let me suggest we rename “testing”
>> to “staging”,
>
>"nextstable"? ;-)
>
>(Not "newstable", though. That could be confusing.)

notyetstable

Grüße
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1p1qu7-0002q9...@swivel.zugschlus.de

Bug#598660: ITP: feed2omb -- Announces new articles in a feed to an open microblogging service

[Raphaël Hertzog]

Package: wnpp
Severity: wishlist
Owner: "Raphaël Hertzog" 

* Package name: feed2omb
  Version : 0.9
  Upstream Author : Ciaran Gultnieks
* URL : http://projects.ciarang.com/p/feed2omb/
* License : GNU Affero General Public License 3
  Programming Lang: Python
  Description : Announces new articles in a feed to an open microblogging 
service

 feed2omb is a simple tool that takes input from Atom or RSS feeds and posts
 updates to the open microblogging service of your choice.
 .
 Features:
  * Flexible processing of multiple feeds
  * Various ways of forming the message from the feed content
  * Ability to apply regular expressions to the message - RegEx
  * Include links or not
  * Support for various URL-shortening services - UrlShortening
  * Auto-generation of hashtags from feed categories - HashTags
  * Configurable rate limiting - FloodControl
  * Support for sending to XMPP as well/instead - XMPP

I'm packaging this because I want to use something like this for
the debian account on identi.ca and I havent't found any better
tool available. It's only a Python script of 375 lines.

If you know of better alternatives, please tell me.



--
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/20100930210739.22506.8209.report...@rivendell.localdomain

Re: Search for a file in all Debian source packages

[Jon Dowland]

I *think*, if Raphael hadn't stepped up first and saved you the bother, you
could probably get this information out of UDD.


-- 
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/20100930211049.ga1...@deckard.alcopop.org

Re: Buildd & binary-indep

[Russ Allbery]

Raphael Hertzog  writes:

> Well, we specified DEB_BUILD_OPTIONS space separated because build flags
> frequently embed commas. Shall we not take the same decision
> preemptively here?

Most fields that take multiple values use commas.  We do have another that
takes spaces (Architecture), but I would much rather use commas.

If the field is space-separated, it can't be folded.  If you want it to be
folded, it has to be comma-separated (unless you're proposing introducing
yet a *fourth* syntax for control fields, which seems like a bad idea).

> Also if we want to have lists as values for some "features" — like
> "disable-hardening=pie,relro" — we'd be better with using space
> separator.

I think that would be a bad idea.  If we need to provide data that takes
additional options, we should add another field, since we already have a
syntax for that.  Not add key-value pairs inside the value of something
that's already a key-value pair.

-- 
Russ Allbery (r...@debian.org)   


--
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/87eicbj613@windlord.stanford.edu

Re: Search for a file in all Debian source packages

[Benjamin Drung]

Am Donnerstag, den 30.09.2010, 14:38 -0400 schrieb Michael Hanke:
> On Thu, Sep 30, 2010 at 08:33:54PM +0200, Benjamin Drung wrote:
> > Am Donnerstag, den 30.09.2010, 14:31 -0400 schrieb Michael Hanke:
> > > Hi,
> > > 
> > > I want to determine in what Debian _source_ packages a file with a
> > > particular name exists. There used to be a webservice that had all?
> > > source packages indexed and allowed for this type of query, but I cannot
> > > remember what it was -- maybe it doesn't exist anymore.
> > 
> > http://www.debian.org/distrib/packages
> > 
> > There you can search the contents of packages.
> 
> _Binary_ packages. This is not what I was looking for.

Oops. IIRC there was a website where you can search the source code, but
this website took the code directly from upstream. So this might not fit
your needs.

-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)


signature.asc
Description: This is a digitally signed message part

Re: Debian source code search engine

[Yaroslav Halchenko]

Following Michael's inquiry  I finally found this thread.

Peter, are there any plans to make Debian's source code indexer alive
again (and may be placed on somewhat permanent/reliable hosting)?

Cheers,

On Sun, 24 May 2009, Peter De Wachter wrote:

> I've set up a search engine which indexes Debian's source code:

>   http://walrus.rave.org/source/

> Currently, unstable main and contrib are indexed, in total 70 gigabytes
> of source. (It would probably be nice to have stable and testing as
> well, but I don't have enough disk space available. I skipped non-free
> in fear of annoying licenses.)

> The software used is OpenGrok, originally developed at
> Sun for OpenSolaris (http://opensolaris.org/os/project/opengrok). It's
> quite nice, although a bit slow with this amount of source code.
-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]




signature.asc
Description: Digital signature

Re: Search for a file in all Debian source packages

[Michael Hanke]

On Thu, Sep 30, 2010 at 02:21:45PM -0500, Raphael Geissert wrote:
> Michael Hanke wrote:
> > Is there any way to accomplish this, without having to create a
> > complete mirror of the archive and parse all tarballs?
> 
> As of a few minutes ago:
> http://lintian.debian.org/~geissert/Contents-sources.gz

Thank you Raphael!


Michael


-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://mih.voxindeserto.de


-- 
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/20100930200547.gb3...@meiner

Re: Buildd & binary-indep

[Raphael Hertzog]

Hi,

On Mon, 27 Sep 2010, Russ Allbery wrote:
> > Well, I don't make it a requirement to implement it right now and the
> > Build-Features code can certainly start with just the build-arch
> > stuff. But I want to make sure we gave it enough thought so that it's
> > not problematic later on to extend it to other similar but slightly
> > different needs.
> 
> Is there anything about the syntax:
> 
> Build-Features: build-arch
> 
> to indicate that the package supports build-arch/build-indep targets (I
> don't see any point in supporting one and not the other) that you think
> would cause a problem for future expansion?  I'd add a note that if there
> are other build features, they'll be a comma-separated list of similar
> keywords.

Well, we specified DEB_BUILD_OPTIONS space separated because build flags
frequently embed commas. Shall we not take the same decision preemptively
here?

Also if we want to have lists as values for some "features" — like
"disable-hardening=pie,relro" — we'd be better with using space separator.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20100930195603.ga19...@rivendell.home.ouaza.com

Re: Search for a file in all Debian source packages

[Raphael Geissert]

Michael Hanke wrote:
> Is there any way to accomplish this, without having to create a
> complete mirror of the archive and parse all tarballs?

As of a few minutes ago:
http://lintian.debian.org/~geissert/Contents-sources.gz

(for the time being, to be updated every four days.)


Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/i82nve$c0...@dough.gmane.org

Re: data.debian.org -- requirements for packages

[Yaroslav Halchenko]

> Also, I do wonder what the highest update frequency should be for data
> packages.
> Some databases for instance release weekly or even daily snapshots, but
> updating a 10g debian package each week probably is not what we want.
I guess my follow-up is the result of being smoke deprived today:

concerning duplicate data if needs to be "applied" and purged (comment
from Simon):

for HUGE DBs with frequent updates -- may be we could come up with data
package chains -- i.e. with some base package version + sequence of
dependent packages with binary deltas which get applied upon
installation? e.g.

data-blob-1.0.0
data-blob-1.0.0+1
data-blob-1.0.0+2
...
?

-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]



--
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/20100930184559.gy12...@onerussian.com

Re: Search for a file in all Debian source packages

[James Vega]

On Thu, Sep 30, 2010 at 2:31 PM, Michael Hanke  wrote:
> I want to determine in what Debian _source_ packages a file with a
> particular name exists. There used to be a webservice that had all?
> source packages indexed and allowed for this type of query, but I cannot
> remember what it was -- maybe it doesn't exist anymore.

This used to be available as source.debian.net.  According to the
wiki[0], there appears to be work starting on a replacement.

[0]: http://wiki.debian.org/source.debian.org
-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


-- 
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/aanlktikpexe2zzlo=x1joj-mdrxgx6w8sxhcmpgoe...@mail.gmail.com

Re: Search for a file in all Debian source packages

[Michael Hanke]

On Thu, Sep 30, 2010 at 08:33:54PM +0200, Benjamin Drung wrote:
> Am Donnerstag, den 30.09.2010, 14:31 -0400 schrieb Michael Hanke:
> > Hi,
> > 
> > I want to determine in what Debian _source_ packages a file with a
> > particular name exists. There used to be a webservice that had all?
> > source packages indexed and allowed for this type of query, but I cannot
> > remember what it was -- maybe it doesn't exist anymore.
> 
> http://www.debian.org/distrib/packages
> 
> There you can search the contents of packages.

_Binary_ packages. This is not what I was looking for.

Michael

-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://mih.voxindeserto.de


-- 
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/20100930183800.ga28...@meiner

Re: Search for a file in all Debian source packages

[Benjamin Drung]

Am Donnerstag, den 30.09.2010, 14:31 -0400 schrieb Michael Hanke:
> Hi,
> 
> I want to determine in what Debian _source_ packages a file with a
> particular name exists. There used to be a webservice that had all?
> source packages indexed and allowed for this type of query, but I cannot
> remember what it was -- maybe it doesn't exist anymore.

http://www.debian.org/distrib/packages

There you can search the contents of packages.

-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)


signature.asc
Description: This is a digitally signed message part

Search for a file in all Debian source packages

[Michael Hanke]

Hi,

I want to determine in what Debian _source_ packages a file with a
particular name exists. There used to be a webservice that had all?
source packages indexed and allowed for this type of query, but I cannot
remember what it was -- maybe it doesn't exist anymore.

Is there any way to accomplish this, without having to create a
complete mirror of the archive and parse all tarballs?

Thanks in advance,

Michael


-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://mih.voxindeserto.de


-- 
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/20100930183103.ga28...@meiner

Re: Buildd & binary-indep

[Joey Hess]

Bernhard R. Link wrote:
> > This smells the same as the /usr/share/doc transition. That took
> > *years* -- and without significant efforts, it would have never finished.
> 
> Sorry. Even if that was comparable and thus true, it still means that this
> is by far the superior solution. Only taking years means it has a
> result and we would have got a useable build-arch by now multiple times.

In case you're actually not aware of the horribleness of that, see
http://bugs.debian.org/322762
The /usr/share/doc/ transition took 8 years to complete. I wasted at
least 2 man-months of my life on it. I'm not the only one, and overall
I'm sure we blew entire man-years of effort on it. IIRC by the time it was
complete the misfeature in dpkg that it worked around had long been
corrected, so the whole thing could have been avoided with a single
mv and symlink. I will never, ever, be involved in such a debacle again.


All we really need is an archive-wide test build using the program in #598534.
I'm fairly confident that it will show that this works for everything:
make-first-existing-target -c debian/rules build-arch build

-- 
see shy jo


signature.asc
Description: Digital signature

Re: data.debian.org -- requirements for packages

[Michael Hanke]

On Thu, Sep 30, 2010 at 06:01:38PM +0100, Simon McVittie wrote:
> On Wed, 29 Sep 2010 at 13:09:03 -0400, Michael Hanke wrote:
> > * compression of content
> > 
> >   Any policy to enforce compressed file formats regarding the stuff 
> > installed
> >   by a data package?
> 
> I think this ought to be case-by-case: some users of large data blobs
> (e.g. Quake 3/Openarena PK3 files) already support compression, but if the
> application that uses the data will be mmap()ing it, compression isn't
> really feasible.
> 
> .deb files are compressed anyway, unless you go to some effort to turn
> that off, so space consumption on mirrors should be about the same either way.

That is correct, but I was more aiming at rules we have to compress some
portions of installed files (e.g. dh_compress).


Michael

-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://mih.voxindeserto.de


-- 
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/20100930170823.ga24...@meiner

Re: Backports service becoming official

[Sandro Tosi]

Hi all,

On Mon, Sep 27, 2010 at 10:14, Stefano Zacchiroli  wrote:
> On Wed, Sep 22, 2010 at 01:19:20PM -0700, Don Armstrong wrote:
>> On Wed, 22 Sep 2010, Stefano Zacchiroli wrote:
>> > From what concerns the BTS, Don's proposal in [2] (the main one, not
>> > the alternative solution) seems reasonable to me and others in the
>> > thread. The proposal also seems to assume a different Maintainer
>> > field for the bpo package, as hinted above, am I wrong Don?
>>
>> Right. The idea here is that there will be an additional recipient for
>> bugs which affect the version present in bpo; in the case where the
>> bug is bpo only, headers in the message will allow maintainers to
>> filter out these bugs in mail and the bug listings.
>
> OK, thanks for the clarification. Still, we need to decide—sort of
> now—whether we need to add support in reportbug for mailing backport
> report bugs to the bpo list or not (and that might require some time, as
> someone needs to do the work, coordinate with the reportbug maintainer
> and with the release team, to check whether there's room to have the
> change in testing or not). Do you think we should add such a support or
> not?

>From a reportbug POV, it's not a big deal to redirect the reports for
bpo packages to something different than sub...@b.d.o. What I need to
know is:

- the address where to send the bugs
- a regular expression (bonus points if already in python format) to
precisely identify bpo packages from the package version
- if we need to implement it (oh, did I mention that a patch would be
awesome?) :)

If I get the thread correctly, this is just a workaround to allow
ow...@b.d.o to have the time to properly implement that in the BTS,
and so this code will be removed at some point in the future: please
correct me if I'm wrong (and note that I'd like to consider this a
temporary fix not a definitive one).

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


--
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/aanlktinrrcgejjn7ho0+g0h=rhcursrhxlh3=giwz...@mail.gmail.com

Re: data.debian.org -- requirements for packages

[Simon McVittie]

On Wed, 29 Sep 2010 at 13:09:03 -0400, Michael Hanke wrote:
> * compression of content
> 
>   Any policy to enforce compressed file formats regarding the stuff installed
>   by a data package?

I think this ought to be case-by-case: some users of large data blobs
(e.g. Quake 3/Openarena PK3 files) already support compression, but if the
application that uses the data will be mmap()ing it, compression isn't
really feasible.

.deb files are compressed anyway, unless you go to some effort to turn
that off, so space consumption on mirrors should be about the same either way.

S


-- 
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/20100930170138.ge30...@reptile.pseudorandom.co.uk

Re: data.debian.org -- requirements for packages

[Peter Palfrader]

On Wed, 29 Sep 2010, Michael Hanke wrote:

> I know that data.debian.org is not yet there, but I wonder whether there
> is already a concept, i.e. a set of requirements that packages have to
> fulfil to qualify for this archive?

Also, I do wonder what the highest update frequency should be for data
packages.

Some databases for instance release weekly or even daily snapshots, but
updating a 10g debian package each week probably is not what we want.

weasel
-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
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/20100930103012.gl9...@anguilla.noreply.org

Re: Buildd & binary-indep

[Bernhard R. Link]

* Joey Hess  [100929 18:33]:
> Bernhard R. Link wrote:
> > There really is no reason to keep build-arch and build-indep optional
> > (the only reason would have been to allow for them becoming widespread
> > on their own and then requiring them once that has no big effect), as
> > every package not supporting them can support them by a single line in
> > debian/rules: "build-arch build-indep: build".
>
> I hope you're not seriously suggesting we need to modify every single
> source package?

I'm more than serious with that. It's easy, doable and the only sane
solution.

> Very very few packages are ever going to need a split build. Pushing
> complexity off onto every other package to enable that is bad design.

I beg to disagree massively. We already have binary-arch and
binary-indep in every package. Having a clear interface ("you have to
have build-arch and build-indep") is in my eyes the least complex
solution possible.

Any wild guessing whether a package supports it or not has not only
had shown suprising failures in the past, but makes things only less
predictable (which is the worst result of complexity).
Any additional decriptive language which describes how to use the primary
interface does not really says "good design" but "design for design not
for functionality" (especially has those additional data brings no
redundancy and no easy way to catch errors like supporting build-arch
and not advertising it, and advertising it without supporting it will
also only be found with the first -B call).

> And yes, "one line" is added complexity. It makes it that much harder to
> learn how the debian source format works.

Now I really have to ask if you are serious.
How is having binary-arch, binary-indep and binary called by one set of
rules and having an optional build-arch, build-indep called by other
rules and having some additional meta information filled out any more easy
to learn then just requsting to have both and them being called by the
same rules?

> This smells the same as the /usr/share/doc transition. That took
> *years* -- and without significant efforts, it would have never finished.

Sorry. Even if that was comparable and thus true, it still means that this
is by far the superior solution. Only taking years means it has a
result and we would have got a useable build-arch by now multiple times.

All those "we need some way to decide if a package supports that and if
there is no way to do that we need a way of the source package that
universally describe build features including if we have that rules or
not" has now failed for about a decade. And I see no reason why this
approach should not fail for another decade, and the decade after this.

> We need to learn from that mistake.

I hope we will learn something from the failure of build-arch, too.
Bikeshedding and overengineering can be an serious harm.

> We
> already know of multiple ways to support split building without
> modifying every source package,

First of all, it's by far not every source package. Everything using
some automagic stuff has no excuse for not supporting them. Everything
doing things more explicitly can just add a little expliciticity here,
and there are enough source packages not needing a split still
supporting it (all of mine, for example).

And more importantly, I fail to see how something can be called a
solution if it does not solve the problem by simply being stuck.

Bernhard R. Link


-- 
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/20100930095213.ga19...@pcpool00.mathematik.uni-freiburg.de

Re: data.debian.org -- requirements for packages

[Simon Richter]

Hi,

On Wed, Sep 29, 2010 at 01:09:03PM -0400, Michael Hanke wrote:

> * compression of content

>   Any policy to enforce compressed file formats regarding the stuff installed
>   by a data package?

Also, how would we deal with data that is to be accessed using a query
engine such as an SQL database?

Installing and importing a dump file isn't that hard -- however that
would mean that the data is duplicated on disk.

   Simon


-- 
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/20100930092537.ga2...@richter