On Wed, Dec 26, 2007 at 04:32:39PM +0000, Neil Williams wrote:
In general, you seem to rant about a lot of things that may make sense
on their own, but they do not seem to have _anything_ to do with a
package being Debian-native or not. More specifically, you try to imply
that a package being versioned Debian native _must_ mean that it is
unportable and buggy.
> That's not the point. It hinders sharing the code. I'm not unaware of
> the issues here, I'm upstream for many of my Debian packages and only a
> few are native. I make double uploads because it helps people package my
> upstream code for Fedora and SuSE and I believe that free software
> should never hinder the sharing of code. Releasing code with the debian/
> directory intact, just complicates the work for other distros.
Why? Is it really a problem to just ignore the debian/ directory when
writing a .spec file? Lots of upstream packages ship directories that do
not contain anything related to the build, why would the debian/
directory be any different?
> How does that look to other upstream teams developing on Fedora? "Oh,
> we'll hack together some rubbish in debian/ since they put useless .spec
> files in their upstream code."
So you think a Debian-native package should contain an useless .spec
file? Otherwise I do not understand what do you want to say.
> > > How are they to know whether the latest native version is Debian
> > > specific or contains useful "upstream" improvements?
> >
> > By reading debian/changelog -- that's what it's for!
>
> So they have to download the new *debian* version just to see what has
> changed when if it was an SF project they could see that the Debian
> release is of no interest to them as they have the .orig.tar.gz. Why
> should people wanting to use your code have to watch (and understand)
> Debian practices to package your POSIX code for a different
> distribution? What about forcing others to make repeated (useless)
> downloads and wasting their time reading Debian webpages / changelogs,
> trying to pick out what they want from the Debian stuff they don't? The
> package can be used outside Debian - why should someone outside Debian
> need to read debian/changelog in the first place!
That already happens when an upstream release contains a fix for
AIX/Solaris/HP-UX/(horrible dictu)Windows. You _do_ have to download the
upstream source or check the upstream website to see if the change is
relevant for Linux or not. How is this any different?
> If the code is not dependent on Debian itself, why should someone from
> another distribution even need to know about how Debian works just
> because upstream happens to be a DD?
Why would they? _You_ insist that they shold know about the Debian
packaging, but they can just completely ignore it and write a .spec file
(or whatever) from scratch just if the debian/ directory would not even
exist.
> Write portable code in the first place and help others. What's wrong
> with that?
What has portability to do with a package being versioned Debian-native
or not?
> Some native packages even 'make install' directly into debian/tmp/ - how
> unfriendly is that?!
You continuously mix normal software/packaging bugs with being versioned
Debian native or not. In my experiences some software (esp. ones that do
_not_ use autoconf but try to invent their own build system) are a real
PITA to install in the way I want, even if their authors never have even
seen a Debian machine. So I don't buy your argument that this attitude
has _any_ relation with being Debian-native or not.
> It's about reuse of code, it is about sharing code and about not
> thinking of Fedora et al as "competition" or a "burden" but as
> colleagues, even friends - people who help us from time to time and who
> should get some help in return.
Er, how does an "rm -rf debian/" command in an (according to you)
distinct upstream release improves code sharing or reusing?!? If
anything it makes life of other packagers harder because they can't peek
for hints about how Debian handles things...
> Would you read the rpm webpage logs to try to work out whether you need
> to package a Fedora update?
AFAIR some packages regularily took patches from RedHat/Fedora when
their upstream went missing and the RedHat/Fedora release became the de
facto upstream. So yes, this happened and undoubtedly will happen in the
future too.
And of course it can also happen in the other direction too when some
other distro decides to import some hunks from Debian's .diff.gz - the
package does not need to be Debian-native in this case either, yet that
other distro would have to follow every new upload in Debian.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
