[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Option to allow packages from backports but without forcing it



On 12 Jul 2020, at 18:39, Pirate Praveen <praveen@onenetbeyond.org> wrote:
> On Sun, Jul 12, 2020 at 21:50, Pirate Praveen <praveen@onenetbeyond.org> wrote:
>>> Erm… I did add buster-backports, the official one.
>>> You absolutely cannot have a thing called buster-backports on the
>>> fasttrack server because that’s too easily confused with the
>>> official one.
>> Let me think about it.
> 
> Usually with the same suite name, I just have to upload the same .changes file when the package enters testing. So changing the name just adds extra busy work (multiple changelog entries and rebuilds) without any real benefit. Like in the case of ruby-faraday, I just had to dput the .changes file I already created for fasttrack/buster-backports to official buster-backports. So I will stick with it unless someone can show me some real advantage.

This response is, quite frankly, extremely rude and disrespectful towards
Thorsten. Your "without any real benefit" completely disregards the original
reason given which, as you can see above is "because that’s too easily confused
with the official one.". As for the approach, do not do this. Seriously.
Whatever your motivation. If seasoned DDs are being confused by you creating
your own thing with an identical name to a core part of Debian, how on earth do
you expect users to not be confused out of their minds? Not to mention it's
going to seriously aggravate those who manage the real backports suites and
those who follow these lists, as there will no doubt be users coming along
complaining about things that apply to your name-hijacked version and not the
actual backports suites. So call it something else; I doubt many DDs will view
your project favourably if you don't. Also, a word of advice: never prioritise
your own convenience over user experience. It portrays you as selfish, and in
this case stubborn, neither of which are a good look.

Now, for some constructive _technical_ advice. You don't need to require
rebuilds if you don't want to. I see two options for what you can do to avoid
that:

1. Manually edit the .changes file, changing Distribution:, and then re-sign.
   You'll need to configure your DAK instance to not have the lintian tag
   distribution-and-changes-mismatch in its lintian.tags though (or override it
   in the package, but that's a bit weird and dangerous).

2. Configure SuiteMappings in your dak.conf to redirect buster-backports
   uploads to buster-foo. That's it. You can present whatever name you like to
   users, and uploads to your service for buster-backports magically end up in
   the right place.

The second one is probably the better approach, though does come with the risk
that anyone can inject a signed -backports .changes file into your service.
That's generally frowned upon, but in this case you probably view it as a
feature. I'm in two minds about that, but that's ultimately up to you running
the service to decide.

What frustrates me is that, had you responded more appropriately and simply
explained your motivations for doing what's currently implemented, we could
have skipped that whole first paragraph and gone straight to solutions which I
believe solve the problem for both sides. If you want people to be more willing
to help you, work with them, not against them, and especially don't disregard
their views. You may find solutions you didn't even know were possible (or even
thought to consider), like I suspect is the case here.

Jess


Reply to: