On Fri, 2 Jan 2009, Steffen Moeller wrote:
Right. This is also what I though. And if Debian's BTS would also cover the
packages in
mentors, then we would be almost there. Though with mentors you only have one
URL to add
to /etc/apt/sources.list. For the PPA you have a URL for every maintainer.
Well, this might be some point - but finally the user gets a package
and if you ask me, I would prefer one additional line in sources.list
instead of several lines. The BTS issue is a valid point in case there
is not yet an official package in the Debian repository.
Ah. This is not what I meant. Everything would stay the way it is now. What PPA
does not
have is a link to SVN, which basically defines us.
Hmmm, this is not my point. I really have a different idea about
SVN - it definetely NOT defines us. Our SVN is just one tool we
are using for packaging and not a definition.
The PPA would be a place to download
packages and to collect bug reports that today go to our mailing list.
Until now I did not had the impression that this would happen very
frequently, but I would not use this as an argument. Having a structured
BTS might be an advantage.
In Morten's case it is the packages for the Torque batch system that are newer
than those
of his that are today shipping with Ubuntu. Since Torque has some stability
issues, one
will not automagically upload to the very latest version. So, in a way a PPA
could be
something that might have the chance to be too unstable for unstable.
Well if something is "too unstable for unstable" we have experimental.
The other thing that you might be missing (or I might be overstressing) is the
limited
availability of time of ours. With so many groups coming up with so many pieces
of
software, and every tool having its reason to exists (some remaining to just be
historic
reasons against which newer versions are to be compared), there is more out
there than we
can deal with properly, at least while there are other things we need to care
about. There
is hence little point in perfectionising every little package that only few
individuals
use.
If it is about saving time I would suggest to follow the freedom principle:
If somebody thinks he is able to save some time by using a certain tool he
should just use it. I personally do not see a chance why I should start
using additional tools to those I know and in how far this should save time.
So I'd regard you hint as interesting and perhaps inspiring for people to
try this, but I do not think that it should be a general recommendation.
A repository outside the main Debian infrastructure might well keep some binary
of
something that otherwise only exists as our debian folders. Should some
community around
that package step forward, then the packaging work will be completed.
Otherwise, the
package will only be archived.
I'd like to suggest you might try this approach (or anybody else who thinks
this approach sounds promissing to get some work done faster) and report about
the success.
Sometimes it is not even the fault of the developer but just some upstream
folks that
refuse to add copyright notices to their source code, which will then not get
past the
ftpmaster. The getData script in our svn would be something that I would like
in a PPA. It
is still too trivial to make much of a Debian package about it.
I fail to see why useful code - trivial or not - should stay in a Debian package
in an external PPA repository instead in an official package.
But it has some good value
and some stronger visibility and easier installability would be good.
So an official Debian package would be the proper way.
I think Debian needs some PPA kind of system. It is a nice way to have newbie
developers
integrated with the system while minimising the harm that anyone could do.
Mentors is
close, but it is not integrated with the rest of Debian, really. It should get
linked with
the BTS at least. I need to think a bit about what it means to have all our
packages that
are not in the distribution uploaded to mentors. I would not mind, of course.
Though we
would not RFS but RFH with that upload. I would not make much use of that
resource,
though, since I don't like mentors in my sources.list (tried that). The
personalised PA I
prefer.
IMHO this part of the discussion should go to debian-devel.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
