Hi Peter,
Thank you for your reply and sorry for not returning a reply promptly --
we were traveling so I did not want to reply in rush without actually
addressing the issues you have mentioned.
> Gah, sorry. I keep wanting to rpely but it always falls through the
> cracks. Also, debian-snapshot@lists.debian.org would probably have
> been the better place and might have given you a reply sooner.
I looked at the mailing list before emailing you directly, but due to a
bulk of CIA notifications for commits, I was not sure if it would
be better attractor of your attention. I have subscribed to it now and
using it as a primary addressee for this thread from now on.
> > > 1. Check with you either there is a slight possibility that you could
> > > provide n.d.n from s.d.o ;) (our preferable solution)
> For having the trees in the /archive part that probably would not be
> such a big problem.
great!
> What I do worry about however is what it does to the package view. I
> looked around a bit in the archive and it's not always clear from
> looking at the version numbers that packages are not the original
> debian ones. Would that confuse users who search for packages by
> name? Probably. Maybe what is needed is for snapshot's package index
> to remember in which archives it saw packages and their versions.
> That'd require quite some hacking and re-thinking but might be the
> Right Thing to do long term.
I agree on all aspects! That is why at web listing at
http://neuro.debian.net packages get presented as belonging to a
specific distribution (Debian vs Ubuntu) and release even though
versions carry descriptive suffixes.
> One example for packages with "weird" or at least non-telling version
> numbers is
> http://neuro.debian.net/debian/pool/main/b/backuppc/backuppc_3.0.0-2.1~etch.apsy0.dsc
> Most other packages seem to have .nd1. as part of their version
> string. (And where is the source for
> http://neuro.debian.net/debian/pool/main/b/boost/libboost-dev_1.33.1-4_amd64.deb?)
sorry about the mess -- those are signs of age, since this repository
(nd for neurodebian) is reincarnation of its predecessor apsy repository
Michael had before. We have tidied it up, there are still some
~apsy-built packages but more obvious victims should be gone now.
Also we still carry some packages built for sid, which was our poor-man
solution to snapshots ;) but from now on we will try to dump those
whenever package is already in Debian proper (or whenever your snapshots
provides snapshots of n.d.n) -- those which are in Debian proper
have been removed.
Also we removed few other packages which had no proper descriptive
version suffix. The only few packages which bear regular Debian-proper
versioning are data packages, which aren't yet in Debian due to awaited
resolution on large data packages issue (those are afni-data, fsl-data,
fsl-feeds).
But even if versions are descriptive, it still would be nice if
snapshot.d.o exposes the association between versions and repositories.
> Also, I am not convinced we want any ubuntu packages in
> snapshot.debian.org. Let them set up their own snapshot or at least
> provide some help and/or infrastructure with debian's.
we agree with you 200% . We are providing ubuntu packages only whenever
it costs us nothing to have them backported (i.e. there is no need in
tuning up packaging/dependencies) or if it is a package of our primary interest
(like our project python-mvpa, or the package we might care about and
promised upstream to make it available for Ubuntus -- e.g. FSL).
So, if it is of any burden -- we don't care about Debian-derivatives to
be snapshotted.
> > > 2. Employ backports.org to get into s.d.o at least some selection
> > > >...<
> That's always a good idea. If you upload to bpo more people can benefit
> from your work too.
It is true. Especially for any package of a generic utility (i.e. not
targeting neuroscience), since if it is neuroscience related, then those
people would be having nd repository in their apt's anyways (long goal
is to have that change, i.e. ship everything within Debian), so benefits
are not that clear atm. But for the generic packages (often build-depends)
we will try to provide proper backports.
> > > 3. Try to roll out our own snapshotting based on your code
> > > (Least preferable since places too much load on us, not sure if we
> > > would manage to cope with it)
> If you decide to go with that I can probably help out by answering
> questions etc.
I saw that the core is in Ruby and got scared a bit that it might be a
bit more challenging since I have no Ruby experience -- I know that it
is a great language, but once again, not sure if it would be worth it,
if you would be generous to go with 1. ;)
Please let me know what else could be done on our side (besides 3.
;) ) -- should we await for snapshot engine to acquire facility to
expose the origin of the package? from a brief look it seems that it is
only relevant for web interface, since physically they would reside
under different archives under
http://snapshot.debian.org/archive/
if that is correct, then we might be all set since nearly all (besides
those 3 data ones I've mentioned above) packages we have, carry the
appropriate suffix now.
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
Attachment:
signature.asc
Description: Digital signature